Mike Jones: self-issued

Musings on Digital Identity

Author: Mike Jones Page 7 of 33

Building the Internet's missing identity layer

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

By

On March 9, 2020

In CBOR, Claims, Cryptography, IETF, Specifications

IETF logoI’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

On March 9, 2020

In IETF, OAuth, Specifications

OAuth logoAs 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:

An HTML-formatted version is also available at:

Allocating a CBOR tag for RFC 3339 date strings

By

On March 9, 2020

In CBOR, IETF, Specifications

IETF logoI 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:

An HTML-formatted version is also available at:

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

By

On March 3, 2020

In Cryptography, IETF, OAuth, OpenID, Specifications

OAuth logoTwo 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.

JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

By

On February 19, 2020

In Claims, Cryptography, IETF, JSON, OAuth, Specifications

OAuth logoThe JSON Web Token Best Current Practices specification is now RFC 8725 and BCP 225. The abstract of the specification is:

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

The JSON Web Token (JWT) specification [RFC 7519] was approved in May 2015, almost five years ago, and has been in production use since at least 2013. This Best Current Practices specification contains a compendium of lessons learned from real JWT deployments and implementations over that period. It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise. Importantly, the BCP introduces no breaking changes to the JWT specification and does not require changes to existing deployments.

The BCP came about as JWTs were starting to be used in new families of protocols and applications, both in the IETF and by others. For instance, JWTs are being used by the IETF STIR working group to enable verification of the calling party’s authorization to use a particular telephone number for an incoming call, providing verified Caller ID to help combat fraudulent and unwanted telephone calls. The advice in the BCP can be used by new JWT profiles and applications to take advantage of what’s been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

OpenID Connect Federation Keynote at January 2020 OpenID Japan Summit

By

On February 18, 2020

In Events, Federation, OpenID

OpenID logoI gave this keynote presentation at the January 2020 OpenID Japan Summit: Enabling Large-Scale Multi-Party Federations with OpenID Connect. View it in PowerPoint or PDF.

Thanks to Roland Hedberg for collaborating on the presentation with me and for being primary author of the OpenID Connect Federation specification.

And as a preview of coming attractions, I’ll also be presenting on OpenID Connect Federation at Identiverse in June 2020.

JWTs helping combat fraudulent and unwanted telephone calls

By

On February 12, 2020

In Claims, IETF, OAuth, Safety, Specifications

IETF logoI wanted to bring two excellent articles by the IETF on work by the STIR working group to combat fraudulent and unwanted telephone calls to your attention:

Abstract: Providers of voice over IP in the United States will be required to implement the IETF’s Secure Telephony Identity Revisited (STIR) protocol as a result of recently enacted legislation to address some of the root causes of illegal robocalling on the telephone network.

Abstract: Recently, the output of the IETF Secure Telephony Identity Revisited (STIR) working group has received considerable attention from service providers, regulators, and the press because it addresses some of the root causes of the illegal robocalling which has crippled the telephone network.

I love this work for two reasons. First, like the rest of you, I receive a huge volume of unwanted and often fraudulent phone calls. I love that engineers and regulators are partnering to take concrete steps to reduce the volume of these illegal and annoying calls.

Second, I love it that the STIR protocols are using JSON Web Tokens (JWTs) under the covers as the format to represent verifiable statements about legitimate uses of telephone numbers, enabling verifiable Caller ID. It’s often said that one sign of a standard having succeeded is that it’s used for things that the inventors never imagined. This is certainly such a case! I’m proud that the JSON Web Token, which we originally designed with digital identity use cases in mind, is now being used in a completely different context to solve a real problem experienced by people every day.

Security Event Token (SET) delivery specifications addressing Area Director reviews

By

On February 7, 2020

In IETF, Safety, Specifications

IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address the Area Director review comments by Benjamin Kaduk. The changes to address Ben’s comments were made in the previous versions (-08 for Push and -07 for Pull.) The latest versions addressed editorial nits.

Thanks to Ben for his thorough reviews! And thanks to Annabelle Backman for reviewing the changes.

The specifications are available at:

HTML-formatted versions are also available at:

COSE and JOSE Registrations for WebAuthn Algorithms spec adding explanatory comments on design decisions

By

On January 27, 2020

In CBOR, Cryptography, FIDO, IETF, JSON, Specifications, W3C

IETF logoThe “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to add explanatory comments on design decisions made that were discussed on the mailing list that Jim Schaad requested be added to the draft.

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 Token Exchange is now RFC 8693

By

On January 15, 2020

In IETF, OAuth, Specifications

OAuth logoThe OAuth 2.0 Token Exchange specification is now RFC 8693. The abstract of the specification is:

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

This specification standardizes an already widely-deployed pattern in production use by Box, Microsoft, RedHat, Salesforce, and many others. Thanks to all of you who helped make a standard for this important functionality!

OpenID eKYC and Identity Assurance Working Group Formed

By

On December 28, 2019

In Claims, OpenID, Specifications

OpenID logoI’m pleased to report that the OpenID eKYC and Identity Assurance Working Group is up and running. The new working group is now the home for the OpenID Connect for Identity Assurance specification. This specification defines a representation for verified claims about end-users. This enables real-world use cases such as electronic driver’s licenses and digitally satisfying Know Your Customer (KYC) requirements.

See the post OpenID Connect for Identity Assurance now has a dedicated home for more information about the working group, including the working group call schedule.

Poll-Based Security Event Token (SET) Delivery spec addressing WGLC and Shepherd comments

By

On November 18, 2019

In IETF, JSON, Specifications

IETF logoThe Poll-Based Security Event Token (SET) Delivery specification has been updated to address Working Group Last Call (WGLC) and Document Shepherd comments received. Thanks to Annabelle Backman for the useful WGLC comments and to Yaron Sheffer for the useful Shepherd comments. This update is intended to enable our area director Benjamin Kaduk to review both the Push and Poll delivery method specifications at the same time.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) sent to the RFC Editor

By

On November 6, 2019

In CBOR, Claims, Cryptography, IETF, Specifications

OAuth logoI’m pleased to report that the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

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).

Thanks to the ACE working group for completing this important specification.

The specification is available at:

An HTML-formatted version is also available at:

COSE and JOSE Registrations for WebAuthn Algorithms spec addressing WGLC comments

By

On October 24, 2019

In CBOR, Cryptography, FIDO, IETF, JSON, Specifications, W3C

IETF logoThe “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to address working group last call (WGLC) feedback received. Thanks to J.C. Jones, Kevin Jacobs, Jim Schaad, Neil Madden, and Benjamin Kaduk for their useful reviews.

The specification is available at:

An HTML-formatted version is also available at:

JSON Web Token Best Current Practices sent to the RFC Editor

By

On October 22, 2019

In Claims, Cryptography, IETF, JSON, OAuth, Specifications

OAuth logoI’m pleased to report that the JSON Web Token (JWT) Best Current Practices (BCP) specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.

Thanks to the OAuth working group for completing this important specification.

The specification is available at:

An HTML-formatted version is also available at:

OpenID Connect Federation draft 09 ready for your review

By

On October 21, 2019

In Events, Federation, OpenID, Specifications

OpenID logoDraft 09 of the OpenID Connect Federation specification has been published at https://openid.net/specs/openid-connect-federation-1_0-09.html. This version of the specification benefitted from in-person review by experts at IIW. Major changes were:

  • Separated entity configuration discovery from operations provided by the federation API.
  • Defined new authentication error codes.

The authors believe that this version should become the second Implementer’s Draft, in preparation for interop testing in the coming year. Please review!

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Gen-ART and SecDir reviews

By

On October 21, 2019

In CBOR, Claims, Cryptography, IETF, Specifications

IETF logoA new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been published addressing the Gen-ART and SecDir review comments. Thanks to Christer Holmberg and Yoav Nir, respectively, for these useful reviews.

The specification is available at:

An HTML-formatted version is also available at:

Using OpenID Connect Self-Issued to Achieve DID Auth

By

On October 10, 2019

In Documentation, Events, OpenID, W3C

OpenID logoMy co-authors and I recently competed the paper Using OpenID Connect Self-Issued to Achieve DID Auth, which was created as a result of discussions at the eighth Rebooting the Web of Trust workshop. The paper’s abstract is:

Proving control of a DID requires proving ownership of a private key corresponding to a public key for the DID. Of course, this could be done with a new DID-specific protocol. However, standard protocols for proving ownership of a public/private key pair already exist.

This paper describes how to reuse the Self-Issued OpenID Connect (SIOP) specification and related protocol messages to prove control of a DID. It describes both why and how to do this. Related topics, such as release of claims, are also touched upon.

Several people came to the workshop wanting to explore how to use the OpenID Connect Self-Issued OpenID Provider functionality to prove control of a Decentralized Identifier (DID), including myself. The paper describes the approach being taken by a number of groups using DIDs, including Microsoft. The paper’s publication is timely, as the W3C DID Working Group has just formed to create a DID standard. Microsoft is an active member of the working group.

Special thanks to Dmitri Zagidulin for getting the paper over the finish line!

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing remaining Area Director comments

By

On October 1, 2019

In CBOR, Claims, Cryptography, IETF, Specifications

IETF logoA new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been published to address the remaining Area Director review comments by Benjamin Kaduk. Thanks to Ludwig Seitz for doing the bulk of the editing for this version.

The specification is available at:

An HTML-formatted version is also available at:

OpenID Presentations at September 2019 OpenID Workshop and IIW

By

On October 1, 2019

In Events, OpenID

OpenID logoI gave the following presentations at the Monday, September 30, 2019 OpenID Workshop at Verizon Media:

I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 1, 2019:

Page 7 of 33

Previous

Next

Powered by WordPress & Theme by Anders Norén