Mike Jones: self-issued

Musings on Digital Identity

Initial Reanimiated JOSE Working Group Specifications Published

By

On May 8, 2023

In CBOR, Claims, Cryptography, IETF, JSON, Privacy, Specifications

IETF logoFollowing a call for adoption by the restarted JSON Object Signing and Encryption (JOSE) Working Group, I’m pleased to report that the three initial working group specifications have been published. They are:

JSON Web Proof, with abstract:

This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a JSON Web Proof (JWP). Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay and support binding mechanisms.

JSON Proof Algorithms, with abstract:

The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof (JWP) and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

JSON Proof Token, with abstract:

JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs).

Thanks to Jeremie Miller and David Waite for helping us get there!

OAuth DPoP specification is in the hands of the RFC Editor

By

On May 3, 2023

In IETF, OAuth, Specifications

OAuth logoThe OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) specification was approved by the IESG and is now in the hands of the RFC Editor in preparation for publication as an RFC. In a related development, the multiple IANA registrations requested by the specification are already in place.

As Vittorio Bertocci wrote, “One of the specs with the highest potential for (positive) impact in recent years.” I couldn’t agree more!

The latest version of the specification is available at:

Implement and deploy early and often!

First Public Working Draft of Securing Verifiable Credentials using JSON Web Tokens

By

On May 2, 2023

In Claims, JSON, Specifications, W3C

W3C logoThe First Public Working Draft (FPWD) of the Securing Verifiable Credentials using JSON Web Tokens (VC-JWT) specification has been published. The FPWD milestone is described in the W3C Process document. This draft is another step on the way to a Native JWT Representation for Verifiable Credentials.

Please review the First Public Working Draft of VC-JWT. Thanks especially to Orie Steele for making this happen!

OpenID Presentations at April 2023 OpenID Workshop and IIW

By

On April 19, 2023

In Events, OpenID

OpenID logoI gave the following presentation at the Monday, April 17, 2023 OpenID Workshop at Microsoft:

I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, April 18, 2023:

OAuth DPoP Nearing Completion

By

On March 31, 2023

In IETF, OAuth, Specifications

OAuth logoFollowing the IETF-wide publication request, we’ve published another DPoP draft that addresses additional review comments received to date. This version is destined for the IESG Telechat on April 13, 2023.

Recent changes as described in the history log are:

  • Add sec considerations sub-section about binding to client identity
  • Explicitly say that nonces must be unpredictable
  • Change to a numbered list in ‘Checking DPoP Proofs’
  • Editorial adjustments
  • Incorporated HTTP header field definition and RFC 8792 ‘\’ line wrapping suggestions by Mark Nottingham

The specification is available at:

Native JWT Representation for Verifiable Credentials

By

On February 10, 2023

In Claims, JSON, Specifications, W3C

W3C logoFor the first time, there is now a native JSON Web Token (JWT) representation for Verifiable Credentials. This representation uses IANA-registered JWT claims whenever applicable. Among other improvements and simplifications, this means that we finally have a Verifiable Credentials representation that doesn’t require the use of JSON-LD.

The native JWT representation explicitly isn’t a mapping from the VC Data Model. This mapping in the VC 1.1 specification resulted in ambiguities about whether to duplicate VC Data Model claims in the VC-JWT representation (the “in addition to” option) or whether to delete them from the VC Data Model representation (the “instead of” option). These ambiguities harmed interoperability. Rather, the 2.0 VC-JWT representation is its own simpler native JWT data structure.

See the new native JWT VC representation in the Version 2 section of the “Securing Verifiable Credentials using JSON Web Tokens” specification. You can also compare it there to the Version 1.1 representation, which is a mapping from the VC Data Model with the “in addition to” and “instead of” choices.

This accomplishment is the product of the vision, passion, and perseverance of many advocates of simplifying Verifiable Credentials. Foremost among them is Orie Steele – my co-editor for the VC-JWT specification. I’ll also observe that the pull request creating this functionality had an unprecedented fifteen approvers – an indication of the broad support for this direction for Verifiable Credentials. I am proud to have played a role in making it happen.

JSON Object Signing and Encryption (JOSE) Working Group Reanimated

By

On January 29, 2023

In CBOR, Cryptography, Events, IETF, JSON, Privacy, Specifications

IETF logoI’m thrilled that the IETF has restarted the JSON Object Signing and Encryption (JOSE) Working Group. It’s chartered to work on JSON- and CBOR-based representations for Zero-Knowledge Proofs (ZKPs), selective disclosure enabling minimal disclosure, and non-correlatable presentation. The representations are planned to use the three-party model of Issuer, Holder, and Verifier utilized by Verifiable Credentials.

See the newly approved JOSE charter at https://datatracker.ietf.org/doc/charter-ietf-jose/03/. The working group will be chaired by Karen O’Donoghue, John Bradley, and John Mattsson, with the assigned area director being Roman Danyliw.

I believe this is a great outcome because the JOSE working group participants already have expertise creating simple, widely-adopted JSON-based cryptographic formats, such as JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK). The new formats will be peers to JWS, JWE, and COSE, reusing elements that make sense, while enabling use of new cryptographic algorithms whose inputs and outputs are not representable in the existing JOSE and COSE formats.

If you’re interested in the work, please join the JOSE mailing list at https://www.ietf.org/mailman/listinfo/jose if you’re not already a member. Also, plan to participate in IETF 116 Yokohama, where we should be able to have the first meeting of the reconstituted working group. I hope to see you there!

As background, the first step in the JOSE rechartering was the JSON Web Proofs (JWP) BoF at IETF 114 in Philadelphia sponsored by Security Area Director Roman Danyliw and chaired by Karen O’Donoghue and John Bradley, during which Jeremie Miller, Kristina Yasuda, Tobias Looker, and I presented. That was follwed by a Virtual Interim JWP BoF in October, 2022, review on the ietf-announce mailing list, and multiple IESG discussions.

All of which brings us back to the (now recurring!) question: “What Would JOSE Do?” Join us and be part of answering it!

What Would Jose Do?

OAuth DPoP Specification Addressing Area Director Review Comments

By

On December 31, 2022

In IETF, OAuth, Specifications

OAuth logoThis week Brian Campbell published an updated OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) draft addressing the Area Director review comments received. Thanks to Roman Danyliw for his useful review!

As Brian wrote, updates in this version of the specifiation were:

  • Updates from Roman Danyliw’s AD review
  • DPoP-Nonce now included in HTTP header field registration request
  • Fixed section reference to URI Scheme-Based Normalization
  • Attempt to better describe the rationale for SHA-256 only and expectations for how hash algorithm agility would be achieved if needed in the future
  • Elaborate on the use of multiple WWW-Authenticate challenges by protected resources
  • Fix access token request examples that were missing a client_id

The specification is available at:

OpenID Presentations at November 2022 OpenID Workshop and IIW

By

On November 15, 2022

In Events, OpenID

OpenID logoI gave the following presentation at the Monday, November 14, 2022 OpenID Workshop at VISA:

I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, November 15, 2022:

The OpenID Connect Logout specifications are now Final Specifications

By

On September 27, 2022

In OpenID, Specifications

OpenID logoThanks to all who helped us reach this important milestone! This was originally announced on the OpenID blog. These now Final specifications are:

Don’t just sign in. Also sign out!

Publication Requested for OAuth DPoP Specification

By

On August 12, 2022

In IETF, OAuth, Specifications

OAuth logoBrian Campbell published an updated OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) draft addressing the shepherd review comments received. Thanks to Rifaat Shekh-Yusef for his useful review!

Following publication of this draft, Rifaat also created the shepherd write-up, obtained IPR commitments for the specification, and requested publication of the specification as an RFC. Thanks all for helping us reach this important milestone!

The specification is available at:

JWK Thumbprint URI is now RFC 9278

By

On August 10, 2022

In Cryptography, IETF, OAuth, OpenID, Specifications

IETF logoThe JWK Thumbprint URI specification has been published as RFC 9278. Congratulations to my co-author, Kristina Yasuda, on the publication of her first RFC!

The abstract of the RFC is:


This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs.

The need for this arose during specification work in the OpenID Connect working group. In particular, JWK Thumbprint URIs are used as key identifiers that can be syntactically distinguished from other kinds of identifiers also expressed as URIs in the Self-Issued OpenID Provider v2 specification.

JSON Web Proofs BoF at IETF 114 in Philadelphia

By

On July 31, 2022

In Events, IETF, JSON, Privacy, Specifications

IETF logoThis week at IETF 114 in Philadelphia, we held a Birds-of-a-Feather (BoF) session on JSON Web Proofs (JWPs). JSON Web Proofs are a JSON-based representation of cryptographic inputs and outputs that enable use of Zero-Knowledge Proofs (ZKPs), selective disclosure for minimal disclosure, and non-correlatable presentation. JWPs use the three-party model of Issuer, Holder, and Verifier utilized by Verifiable Credentials.

The BoF asked to reinstate the IETF JSON Object Signing and Encryption (JOSE) working group. We asked for this because the JOSE working group participants already have expertise creating simple, widely-adopted JSON-based cryptographic formats, such as JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK). The JWP format would be a peer to JWS and JWE, reusing elements that make sense, while enabling use of new cryptographic algorithms whose inputs and outputs are not representable in the existing JOSE formats.

Presentations given at the BoF were:

You can view the BoF minutes at https://notes.ietf.org/notes-ietf-114-jwp. A useful discussion ensued after the presentations. Unfortunately, we didn’t have time to finish the BoF in the one-hour slot. The BoF questions unanswered in the time allotted would have been along the lines of “Is the work appropriate for the IETF?”, “Is there interest in the work?”, and “Do we want to adopt the proposed charter?”. Discussion of those topics is now happening on the jose@ietf.org mailing list. Join it at https://www.ietf.org/mailman/listinfo/jose to participate. Roman Danyliw, the Security Area Director who sponsored the BoF, had suggested that we hold a virtual interim BoF to complete the BoF process before IETF 115 in London. Hope to see you there!

The BoF Presenters:

JWP BoF Presenters

The BoF Participants, including the chairs:

JWP BoF Participants

OAuth DPoP Presentation at Identiverse 2022

By

On June 29, 2022

In Events, IETF, OAuth, Specifications

OAuth logoHere’s the DPoP presentation that Pieter Kasselman and I gave at the 2022 Identiverse conference:

  • Bad actors are stealing your OAuth tokens, giving them control over your information – OAuth DPoP (Demonstration of Proof of Possession) is what we’re doing about it (PowerPoint) (PDF)

A few photographs that workation photographer Brian Campbell took during the presentation follow.

Mike Presenting:

Mike Presenting

Who is that masked man???

Who is that masked man???

Pieter Presenting:

Pieter Presenting

JWK Thumbprint URI Draft Addressing IETF Last Call Comments

By

On May 16, 2022

In Claims, Cryptography, IETF, OAuth, OpenID

OAuth logoKristina Yasuda and I have published a new JWK Thumbprint URI draft that addresses the IETF Last Call comments received. Changes made were:

  • Clarified the requirement to use registered hash algorithm identifiers.
  • Acknowledged IETF Last Call reviewers.

The specification is available at:

OAuth DPoP Specification Addressing WGLC Comments

By

On May 4, 2022

In Events, IETF, OAuth, Specifications

OAuth logoBrian Campbell has published an updated OAuth DPoP draft addressing the Working Group Last Call (WGLC) comments received. All changes were editorial in nature. The most substantive change was further clarifying that either iat or nonce can be used alone in validating the timeliness of the proof, somewhat deemphasizing jti tracking.

As Brian reminded us during the OAuth Security Workshop today, the name DPoP was inspired by a Deutsche POP poster he saw on the S-Bahn during the March 2019 OAuth Security Workshop in Stuttgart:

Deutsche POP in Stuttgart

He considered it an auspicious sign seeing another Deutsche PoP sign in the Vienna U-Bahn during IETF 113 the same day WGLC was requested!

Deutsche POP in Vienna

The specification is available at:

OpenID Presentations at April 2022 OpenID Workshop and IIW

By

On April 26, 2022

In Events, OpenID

OpenID logoI gave the following presentations at the Monday, April 25, 2022 OpenID Workshop at Google:

I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, April 26, 2022:

Two new COSE- and JOSE-related Internet Drafts with Tobias Looker

By

On March 5, 2022

In CBOR, Claims, IETF, JSON, Specifications

IETF logoThis week, Tobias Looker and I submitted two individual Internet Drafts for consideration by the COSE working group.

The first is “Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE“, the abstract of which is:


This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key).

These curves are used in Zero-Knowledge Proof (ZKP) representations for JOSE and COSE, where the ZKPs use the CFRG drafts “Pairing-Friendly Curves” and “BLS Signatures“.

The second is “CBOR Web Token (CWT) Claims in COSE Headers“, the abstract of which is:


This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload.

JWTs define a mechanism for replicating claims as header parameter values, but CWTs have been missing the equivalent capability to date. The use case is the same as that which motivated Section 5.3 of JWT “Replicating Claims as Header Parameters” – encrypted CWTs for which you’d like to have unencrypted instances of particular claims to determine how to process the CWT prior to decrypting it.

We plan to discuss both with the COSE working group at IETF 113 in Vienna.

Minor Updates to OAuth DPoP Prior to IETF 113 in Vienna

By

On March 3, 2022

In IETF, OAuth, Specifications

OAuth logoThe editors have applied some minor updates to the OAuth DPoP specification in preparation for discussion at IETF 113 in Vienna. Updates made were:

  • Renamed the always_uses_dpop client registration metadata parameter to dpop_bound_access_tokens.
  • Clarified the relationships between server-provided nonce values, authorization servers, resource servers, and clients.
  • Improved other descriptive wording.

The specification is available at:

Four Months of Refinements to OAuth DPoP

By

On February 20, 2022

In IETF, OAuth, Specifications

OAuth logoA new draft of the OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP) specification has been published that addresses four months’ worth of great review comments from the working group. Refinements made were:

  • Added Authorization Code binding via the dpop_jkt parameter.
  • Described the authorization code reuse attack and how dpop_jkt mitigates it.
  • Enhanced description of DPoP proof expiration checking.
  • Described nonce storage requirements and how nonce mismatches and missing nonces are self-correcting.
  • Specified the use of the use_dpop_nonce error for missing and mismatched nonce values.
  • Specified that authorization servers use 400 (Bad Request) errors to supply nonces and resource servers use 401 (Unauthorized) errors to do so.
  • Added a bit more about ath and pre-generated proofs to the security considerations.
  • Mentioned confirming the DPoP binding of the access token in the list in (#checking).
  • Added the always_uses_dpop client registration metadata parameter.
  • Described the relationship between DPoP and Pushed Authorization Requests (PAR).
  • Updated references for drafts that are now RFCs.

I believe this brings us much closer to a final version.

The specification is available at:

Page 3 of 32

Previous

Next

Powered by WordPress & Theme by Anders Norén