Month: March 2020

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) is now RFC 8747

On March 9, 2020

In CBOR, Claims, Cryptography, IETF, Specifications

I’m pleased to report that Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) is now RFC 8747. The abstract of the specification is:

This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)” (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).

This is one of a series of specifications, including CWT [RFC 8392] — which mirrors JWT [RFC 7519], in which we are intentionally bringing functionality that is available in JSON to the CBOR and IoT world.

OAuth 2.0 DPoP for the Implicit Flow

By Mike Jones

On March 9, 2020

In IETF, OAuth, Specifications

OAuth logo As I previously described, members of the OAuth working group have developed a simplified approach to providing application-level proof-of-possession protections for OAuth 2.0 access tokens and refresh tokens. This approach is called OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP). Among other benefits, this approach does not require a complicated and error-prone procedure for signing HTTP requests, as some past approaches have.

However, the DPoP specification to date has assumed that the client is using the OAuth authorization code flow. As promised at the last IETF meeting, we’ve now published a simple companion specification that describes how DPoP can be used with the OAuth implicit flow — in which access tokens are returned directly from the authorization endpoint. The specification is mercifully brief because very little had to be added to supplement the existing DPoP spec to enable use of DPoP with the implicit flow. Thanks to Brian Campbell and John Bradley for whiteboarding this solution with me.

Finally, in a related development, it was decided during the OAuth virtual interim meeting today to call for working group adoption of the core DPoP draft. That’s an important step on the journey towards making it a standard.

The specification is available at:

https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00

An HTML-formatted version is also available at:

https://self-issued.info/docs/draft-jones-oauth-dpop-implicit-00.html

Allocating a CBOR tag for RFC 3339 date strings

By Mike Jones

On March 9, 2020

In CBOR, IETF, Specifications

I have published the specification Concise Binary Object Representation (CBOR) Tag for Date to allocate a CBOR tag for RFC 3339 full-date values. While there’s already a tag for date-time values, there’s currently no tag allocated for full-date values — a date string without a time. The need for this arose for the ISO Mobile Driver’s License specification in the working group ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification”.

Thanks to Carsten Bormann for pointers on the best way to accomplish this.

The specification is available at:

https://tools.ietf.org/html/draft-jones-cbor-date-tag-00

An HTML-formatted version is also available at:

https://self-issued.info/docs/draft-jones-cbor-date-tag-00.html

Two New OAuth RFCs: MTLS (RFC 8705) and Resource Indicators (RFC 8707)

By Mike Jones

On March 3, 2020

In Cryptography, IETF, OAuth, OpenID, Specifications

OAuth logo Two widely used OAuth specifications have recently become RFCs. Here’s a bit about both specs.

RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

Abstract: This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.

Client certificates are widely used in the financial industry to authenticate OAuth clients. Indeed, this specification was developed in part because it was needed by the OpenID Financial-Grade API (FAPI) specifications. It is in production use by numerous Open Banking deployments today.

RFC 8707: Resource Indicators for OAuth 2.0

Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.

This specification standardizes the “resource” request parameter that is used by Azure Active Directory (AAD) V1 to specify the target resource for an OAuth authorization request.