Mesages - 2.1.2.1 "azp" definition too restrictive

[Nat Sakimura]

Currently:

azp
OPTIONAL. Authorized Party. This member identifies an OAuth 2.0 
client authorized to use this ID Token as an OAuth access token, 
if different than the Client that requested the ID Token. It MUST contain 
the client_id of the authorized party.

Proposal:

azp
OPTIONAL. Authorized Party. This member identifies an OAuth 2.0 
client authorized to use this ID Token as an OAuth access token. 
It MUST contain the identifier that the protected resource recognizes.

Rationale:

Current text needlessly constrains what azp could be, while that constraint being not necessarily useful. For example, the current definition removes the possibility of having ephemeral identifier (such as a dynamically generated public key) of the client, which is not a client_id in the OAuth sense but still useful as long as the protected resource can recognize it and possibly perform the key possession check.

[Michael Jones]

The "if" language should be changed to say that "azp" is OPTIONAL when the authorized party is the Client that requested the ID Token.

The working group is against the second change that would not require "azp" to be the client_id.

[Michael Jones]

Fixed #712 - "azp" definition clarification

→ <<cset 81ed6cf7f840>>

[Former user]

(Reply via [e-mail]):

Please drop "as an OAuth access token". What about "as an assertion of the identity of the subject suitable for authenticating the subject to the specified audience."

[Nat Sakimura]

Breno's comment is not yet resolved.

[Nat Sakimura]

azp
OPTIONAL. Authorized Presenter. This member identifies an OAuth 2.0 Client 
authorized to use this ID Token. It MUST contain the client_id of 
the Authorized Presenter.

[Michael Jones]

We agreed on the call to delete the phrase "as an OAuth access token". We don't think it's necessary to add the second phrase, which is confusing - at least as written.

[Nat Sakimura]

It is now John's turn to come up with the specific amended text as per Apr. 4 call.

[gffletch]

azp OPTIONAL. This field identifies the entity presenting the ID Token to the resource endpoint and SHOULD contain a value verifiable by the resource endpoint.

[gffletch]

Possible text for the 'aud' field in the Messages spec 2.1.2.1

aud REQUIRED. Audience that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Client and MAY additionally contain other audience identifiers as necessary.

[gffletch]

Messages - Section 5.2 - ID_TOKEN Validation

Step 3. If the token contains an 'azp' value (may be a list) the client SHOULD validate the value(s) of the azp however the mechanism to validate such values is outside the scope of this document.

[gffletch]

Need to make 'azp' multi-valued. Same model as 'aud' field from JWT.

In the general case, the "azp" value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "azp" value MAY be a single case sensitive string containing a StringOrURI value.

[Michael Jones]

Fixed #712 - Clarified the "azp" description and made "azp" multi-valued, like "aud". Fixed #830 - Clarified that "aud" of an ID Token must contain the Client ID of the Relying Party.

→ <<cset fd362360436a>>

[Nat Sakimura]

Temporarily reopening as there is a new ticket #973 which is essentailly a dup of it. Also, since some of the things which happened after the fact was not recorded, I am now recording them after reopening it.

[Nat Sakimura]

Apparently, in the May 6, 2013 F2F, there was a discussion and decision around it. The meeting note is available as: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130506/003466.html

The relevant part of the note is as follows:

Expected behavior of time fields when using Refresh Tokens
   We determined that the language in Messages 2.2.3 (Access Token Response) 
   needs a few enhancements
   We need to include "aud" in the list of elements that must be the same
   We will further clarify that "azp" must be the same
   We will format the requirements as a bulleted list, for better readability

Review audience/azp semantics
   We will clarify that when an ID Token is used as a hint, that the party 
   receiving the hint need not be an audience of the token
   Relying parties expressed a need to be able to know who the ID Token is issued to
      We decided that we will use the "azp" field for this
      "azp" will be single-valued
      While ideally this would be named something closer to "issued to", 
      we will leave the name "azp" 
      so as not to break existing deployments
      Breno pointed out that originally we had an issued_to field 
      but that it was removed.  
      This brings us full circle.

Attached images are: * http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0005.jpg * http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0006.jpg

[Michael Jones]

The “azp” description was updated after the in-person OpenID Connect working group meeting at Google on 6-May-13, in which we agreed that “azp” would be used to represent the issued-to information, and that the claim would be named “Authorized Party”. See the meeting notes at http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130506/003466.html, including attachment http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0005.jpg, which documents that we decided to represent issued-to information with “azp” and attachment http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0006.jpg, which documents that the “azp” claim is to represent an “Authorized Party”. We also decided to make “azp” single-valued there, where it had previously been multi-valued.

Breno de Medeiros and Naveen Agarwal of Google were at the meeting, and in fact, were behind many of these changes, which is significant, since they were the inventors of this functionality. They concurred with and participated developing these resolutions previously open issues about the meanings of “aud” and “azp”. Afterwards, the meeting notes were sent to the working group mailing list for review there and no objections were raised.

Furthermore, all of this text went through both the 45 day Implementer’s Draft 2 public review period announced at http://openid.net/2013/06/07/review-of-proposed-openid-connect-implementers-drafts/ and the 60 day Final Specification public review period announced at http://openid.net/2013/12/20/review-of-proposed-final-openid-connect-specifications-and-implementers-drafts/, and no objections were raised during those reviews either. People seemed happy with the resolution arrived at during the working group meeting.

So in conclusion, it would probably be less confusing to all concerned if people were to stop referring to “azp” as “authorized presenter” or ascribing those semantics to it (whatever those may be). Sometime before Implementer’s Draft 2 of OpenID Connect that terminology was used, but the working group changed that and the meaning of “azp” by consensus in May 2013 and it’s been that way ever since. Trying to overload “azp” with a different meaning than what’s in the standard seems counterproductive.

This is all documented now both in the working group mailing list archives and the issue tracker, so I'm re-closing the bug.