Mesages - 2.1.2.1 "azp" definition too restrictive

Issue #712 resolved
Nat Sakimura
created an issue

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.

Comments (18)

  1. Breno de Medeiros

    (Reply via bren...@gmail.com):

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

  2. Nat Sakimura reporter
    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.
    
  3. 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.

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

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

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

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

  8. Nat Sakimura reporter
    • changed status to open

    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.

  9. Nat Sakimura reporter

    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

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

  11. Log in to comment