Security Event Token (SET) delivery specifications updated in preparation for IETF 104


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address working group feedback received, in preparation for discussions at IETF 104 in Prague. The Push Delivery spec went through working group last call (WGLC). It has been updated to incorporate the WGLC comments. Changes made are summarized in the spec change log, the contents of which were also posted to the working group mailing list. Thanks to Annabelle Backman for the edits to the Push Delivery spec.

It’s worth noting that the Push Delivery spec and the Security Event Token (SET) are now being used in early Risk and Incident Sharing and Coordination (RISC) deployments, including between Google and Adobe. See the article about these deployments by Mat Honan of BuzzFeed.

Changes to the Poll Delivery spec are also summarized in that spec’s change log, which contains:

OAuth Device Flow spec renamed to “OAuth 2.0 Device Authorization Grant”


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




OAuth logoResponding to feedback from multiple parties that the title “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices” was too much of a mouthful, the title of the specification has been simplified to “OAuth 2.0 Device Authorization Grant”. Likewise, we received feedback that “Device flow” was an insider term that caused more confusion than clarity, so its use has been removed from the specification. Finally, last minute feedback was received that client authorization and error handling were not explicitly spelled out. The specification now says that these occur in the same manner as in OAuth 2.0 [RFC 6749].

Many thanks to William Denniss for performing these edits! Hopefully this will be the draft that is sent to the RFC Editor.

The specification is available at:

An HTML-formatted version is also available at:

Additional COSE algorithms used by W3C Web Authentication (WebAuthn)


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoThe new COSE working group charter includes this deliverable:

4. Define the algorithms needed for W3C Web Authentication for COSE using draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k1 as a starting point (Informational).

I have written draft-jones-cose-additional-algorithms, which combines these starting points into a single draft, which registers these algorithms in the IANA COSE registries. When not already registered, this draft also registers these algorithms for use with JOSE in the IANA JOSE registries. I believe that this draft is ready for working group adoption to satisfy this deliverable.

The specification is available at:

An HTML-formatted version is also available at:

FIDO2 Client to Authenticator Protocol (CTAP) standard published


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




FIDO logoI’m thrilled to report that the FIDO2 Client to Authenticator Protocol (CTAP) is now a published FIDO Alliance standard! Together with the now-standard Web Authentication (WebAuthn) specification, this completes standardization of the APIs and protocols needed to enable password-less logins on the Web, on PCs, and on and mobile devices. This is a huge step forward for online security, privacy, and convenience!

The FIDO2 CTAP standard is available in HTML and PDF versions at these locations:

The W3C Web Authentication (WebAuthn) specification is now a standard!


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




W3C logoI’m thrilled to report that the Web Authentication (WebAuthn) specification is now a W3C standard! See the W3C press release describing this major advance in Web security and convenience, which enables logging in without passwords. Alex Simons, Microsoft Vice President of Identity Program Management is quoted in the release, saying:

“Our work with W3C and FIDO Alliance, and contributions to FIDO2 standards have been a critical piece of Microsoft’s commitment to a world without passwords, which started in 2015. Today, Windows 10 with Microsoft Edge fully supports the WebAuthn standard and millions of users can log in to their Microsoft account without using a password.”

The release also describes commitments to the standard by Google, Mozilla, and Apple, among others. Thanks to all who worked on the standard and who built implementations as we developed the standard – ensuring that that the standard can be used for a broad Continue reading "The W3C Web Authentication (WebAuthn) specification is now a standard!"

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec fixing nits


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoThe Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to address issues identified by Roman Danyliw while writing his shepherd review. Thanks to Samuel Erdtman for fixing an incorrect example.

The specification is available at:

An HTML-formatted version is also available at:

W3C Web Authentication (WebAuthn) advances to Proposed Recommendation (PR)


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




W3C logoThe World Wide Web Consortium (W3C) has published a Proposed Recommendation (PR) for the Web Authentication (WebAuthn) specification, bringing WebAuthn one step closer to becoming a completed standard. The Proposed Recommendation is at https://www.w3.org/TR/2019/PR-webauthn-20190117/.

The PR contains only clarifications and editorial improvements to the second Candidate Recommendation (CR), with no substantial changes. The next step will be to publish a Recommendation – a W3C standard – based on the Proposed Recommendation.

OpenID Connect Federation Specification


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




OpenID logoThe OpenID Connect Federation 1.0 specification is being developed to enable large-scale federations to be deployed using OpenID Connect. It enables trust among federation participants to be established through signed statements made by federation operators about federation participants.

The design of this specification builds upon the experiences gained in operating large-scale SAML 2.0 federations, and indeed, is authored by people having practical experience with these federations. The primary authors are Roland Hedberg and Andreas Åkre Solberg, with additional contributions by Samuel Gulliksson, John Bradley, and myself, as well as members of the OpenID Connect working group, which is the home of the specification.

A key innovation that differentiates OpenID Connect federations from most SAML 2.0 federations is that OpenID Connect federation employs heirarchal metadata, where participants directly publish statements about themselves, versus the aggregated metadata approach used by many SAML 2.0 federations, where Continue reading "OpenID Connect Federation Specification"

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec adding Key ID considerations


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoKey ID confirmation method considerations suggested by Jim Schaad have been added to the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification. Per discussions in the working group meeting in Bangkok, it’s now time for the shepherd review.

The specification is available at:

An HTML-formatted version is also available at:

JWT BCP updates addressing Area Director review comments


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




OAuth logoThe JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the review comments from Security Area Director (AD) Eric Rescorla. Thanks to Eric for the review and to Yaron Sheffer for working on the responses with me.

Note that IETF publication has already been requested. The next step is for the shepherd review to be submitted and responded to.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing additional WGLC comments


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoThe Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to addresses a few additional Working Group Last Call (WGLC) comments. All of the (few) changes were about improving the clarity of the exposition. I believe that this completes addressing the WGLC comments.

Thanks to Roman Danyliw for helping to categorize the remaining comments that needed to be addressed.

The specification is available at:

An HTML-formatted version is also available at:

Security Event Token (SET) delivery specifications updated


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoNow that the Security Event Token (SET) specification is RFC 8417, the SecEvent working group is working on defining the SET delivery mechanisms. This week, both the push-based and poll-based SET delivery specs have been updated to simplify their exposition and reduce duplication of text between the drafts. Thanks to Annabelle Backman for doing the bulk of the recent work on the push-based delivery spec. The latest versions of both specs contain these updates:

  • Addressed problems identified in my 18-Jul-18 review message titled “Issues for both the Push and Poll Specs”.
  • Changes to align terminology with RFC 8417, for instance, by using the already defined term SET Recipient rather than SET Receiver.
  • Applied editorial and minor normative corrections.
  • Updated Marius Scurtescu’s contact information.

In addition, the latest version of the poll delivery spec also contains this update:

The core Token Binding specs are now RFCs 8471, 8472, and 8473


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoThe IETF Token Binding working group has completed the core Token Binding specifications. These new standards are:

  • RFC 8471: The Token Binding Protocol Version 1.0
  • RFC 8472: Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
  • RFC 8473: Token Binding over HTTP

As Alex Simons recently wrote, it’s time for token binding. Especially now that the core specs are done, now’s the time for platforms and applications to deploy Token Binding. This will enable replacing bearer tokens, which can be stolen and reused, with Token Bound tokens, which are useless if stolen. This is a huge security benefit applicable to any tokens used over TLS, including browser cookies, OAuth access tokens and refresh tokens, and OpenID Connect ID Tokens.

Congratulations especially to the editors Andrei Popov, Dirk Balfanz, Jeff Hodges, Magnus Nyström, and Nick Harper and the chairs John Bradley and Leif Johansson for getting Continue reading "The core Token Binding specs are now RFCs 8471, 8472, and 8473"

It’s Time for Token Binding


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoCheck out Alex Simons’ and Pamela Dingle’s blog post “It’s Time for Token Binding”. Now that the IETF Token Binding specs are essentially done, it’s time to ask those who write TLS software you use to ship Token Binding support soon, if they haven’t already done so.

Token Binding in a nutshell: When an attacker steals a bearer token sent over TLS, he can use it; when an attacker steals a Token Bound token, it’s useless to him.

Second W3C Web Authentication (WebAuthn) Candidate Recommendation (CR)


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




W3C logoW3C has published a second W3C Candidate Recommendation (CR) for the Web Authentication (WebAuthn) specification. The second Candidate Recommendation is at https://www.w3.org/TR/2018/CR-webauthn-20180807/.

This draft contains a few refinements since the first candidate recommendation but no substantial changes. The new CR was needed to fulfill the W3C’s IPR protection requirements. The few changes were based, in part, upon things learned during multiple interop events for WebAuthn implementations. The working group plans to base coming the Proposed Recommendation on this draft.

IETF Token Binding specifications sent to the RFC Editor


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoThe three core IETF Token Binding Specifications have been sent to the RFC Editor, which means that their normative content will no longer change. It’s time to move implementations to version 1.0! The abstract of the Token Binding over HTTP specification describes Token Binding as:

This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.

We describe both first-party and federated scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.

Federated token bindings, on the other hand, allow Continue reading "IETF Token Binding specifications sent to the RFC Editor"

Security Event Token (SET) is now RFC 8417


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




IETF logoThe Security Event Token (SET) specification is now RFC 8417. The abstract describes the specification as:

This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.

SETs are already in use to represent OpenID Connect Back-Channel Logout tokens and to represent Risk and Incident Sharing and Coordination (RISC) events. Thanks to my co-editors, members of the IETF ID Events mailing list, and members of the IETF Security Continue reading "Security Event Token (SET) is now RFC 8417"

OpenID Connect Token Binding Specification Updated


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




OpenID logoThe OpenID Connect Token Bound Authentication specification has been updated in response to developer feedback and in anticipation of the IETF Token Binding specifications finishing. Changes were:

  • Adjusted the metadata to indicate supported confirmation method hash algorithms for Token Binding IDs in ID Tokens.
  • Updated references for draft-ietf-tokbind-protocol to -19, draft-ietf-tokbind-https to -17, draft-ietf-oauth-token-binding to -07, and draft-ietf-oauth-discovery to -10.
  • Explicitly stated that the base64url encoding of the “tbh” value doesn’t include any trailing pad characters, line breaks, whitespace, etc.

(The representation of the Token Binding ID in the ID Token is unchanged.)

Thanks to Brian Campbell for doing the editing for this draft.

The specification is available at:

OAuth 2.0 Authorization Server Metadata is now RFC 8414


This post is by Mike Jones from Mike Jones: self-issued


Click here to view on the original site: Original Post




OAuth logoThe OAuth 2.0 Authorization Server Metadata specification is now RFC 8414. The abstract describes the specification as:

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

The specification defines a JSON metadata representation for OAuth 2.0 authorization servers that is compatible with OpenID Connect Discovery 1.0. This specification is a true instance of standardizing existing practice. OAuth 2.0 deployments have been using the OpenID Connect metadata format to describe their endpoints and capabilities for years. This RFC makes this existing practice a standard.

Having a standard OAuth metadata format makes it easier for OAuth clients to configure connections to OAuth authorization servers. See https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata for the initial set of registered metadata values.

Thanks to all of Continue reading "OAuth 2.0 Authorization Server Metadata is now RFC 8414"