[Openid-specs-ab] aud & azp

Tue Aug 11 01:45:51 UTC 2015

Just posted a comment on the ticket. Please have a look.

2015-08-11 10:03 GMT+09:00 Mike Jones <Michael.Jones at microsoft.com>:

> Yes, the spec requires that the requestor’s Client ID be returned as an
> “aud”.  If present, the “azp” claim can either contain this Client ID or
> another value identifying another party that the requester will also pass
> the token to.
>
>
>
> In retrospect, we probably should have just required that this party be an
> additional “aud” value, but that’s water under the bridge now.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] *On
> Behalf Of *Justin Richer
> *Sent:* Monday, August 10, 2015 5:25 PM
> *To:* Brian Campbell
> *Cc:* openid-specs-ab at lists.openid.net Ab
>
> *Subject:* Re: [Openid-specs-ab] aud & azp
>
>
>
> I agree with Brian’s reading on this, and our client software actually
> enforces this when it’s checking things.
>
>
>
>  — Justin
>
>
>
> On Aug 10, 2015, at 6:10 PM, Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
>
>
> It's not totally clear what the spec allows or prescribes, which is where the
> issue for errata
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbitbucket.org%2fopenid%2fconnect%2fissues%2f973%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6da24809a22c47ac916008d2a1e34e20%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1X6TMVZkgP6mCuDtNEy4RboKjyzk1OaMTBXQU4OkY00%3d>
> originates. And there seems, from the last call anyway
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fpipermail%2fopenid-specs-ab%2fWeek-of-Mon-20150803%2f005637.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6da24809a22c47ac916008d2a1e34e20%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QtgrqR6j0IUHMsE1ObrVUMBMmmiptvGa0cwnVrYkEks%3d>,
> to be a lack of agreement about what the intent actually was.
>
>
> It's my belief that the client id of the RP/client that made the
> authentication request should always be represented in the aud of the
> returned ID Token.
>
>
>
>
>
> On Mon, Aug 10, 2015 at 12:51 PM, Preibisch, Sascha H <
> Sascha.Preibisch at ca.com> wrote:
>
> Just to make sure that I got it right:
>
>    - it is possible that a JWT does not include the client_id (neither in
>    “aud" nor in “azp") of the client who has sent the request, correct?
>
> If I am wrong I may misunderstood your text Brian and would be happy for
> some clarification.
>
>
>
> Thanks, Sascha
>
>
>
> *From: *Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on
> behalf of Brian Campbell <bcampbell at pingidentity.com>
> *Date: *Thursday, August 6, 2015 at 5:47 AM
> *To: *Mike Jones <Michael.Jones at microsoft.com>
> *Cc: *"<openid-specs-ab at lists.openid.net>" <
> openid-specs-ab at lists.openid.net>
> *Subject: *Re: [Openid-specs-ab] aud & azp
>
>
>
> Sure, https://bitbucket.org/openid/connect/issues/973/
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbitbucket.org%2fopenid%2fconnect%2fissues%2f973%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6da24809a22c47ac916008d2a1e34e20%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1X6TMVZkgP6mCuDtNEy4RboKjyzk1OaMTBXQU4OkY00%3d>
>
>
>
> On Wed, Aug 5, 2015 at 5:13 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
> Thanks for bringing this up, Brian.  Could you file this as an issue
> against the “errata” deliverable and the core spec at
> https://bitbucket.org/openid/connect/issues?status=new&status=open
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbitbucket.org%2fopenid%2fconnect%2fissues%3fstatus%3dnew%26status%3dopen&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6da24809a22c47ac916008d2a1e34e20%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CGNQaZLJDEyJwnLJ3nf6XHz0ceOqet%2bdURZK%2b6a3gfU%3d>?
> We should talk about this on tomorrow morning’s working group call.  After
> you do, I’ll add the following as a comment on the issue…
>
>
>
> I think the problematic language is “the Client” in the statement below:
>
>
>
> If an azp (authorized party) Claim is present, the Client SHOULD verify
> that its client_id is the Claim Value.
>
>
>
> The problem is that the azp Client can be different than the requesting
> client.  It’s the azp Client that needs to do this validation step, not the
> requesting client.  Do people agree with this?
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] *On
> Behalf Of *Brian Campbell
> *Sent:* Wednesday, August 05, 2015 10:11 AM
> *To:* <openid-specs-ab at lists.openid.net>
> *Subject:* [Openid-specs-ab] aud & azp
>
>
>
> I find the text around azp and aud to be rather unclear and I think
> there's a potential item for errata in it somewhere.
>
> From the definition of "aud" in JWT
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgVDJXRprGpK9ESVc5UcfRhoeVyqF4FqAreai1hKE%2b8%3d>
> and its use in Connect's ID Token
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d>
> (relevant spec text is copied below), it seems that that the client id of
> the client/RP that made the authentication request has to be one of the
> values, or the only value, of the "aud" claim in the ID Token. That's
> logical and consistent and provides reliable and interoperable guidance to
> implementers about producing and consuming the ID Token. I think that the
> client id of the RP/client that made the authentication request should
> always be represented in the aud of the returned ID Token.
>
> The text around "azp" in the ID Token section
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d>
> and the ID Token Validation section
> <https://na01.safelinks.protection.outlook.com/?url=+http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDTokenValidation&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LrFoSF%2bqjC75ilCneT3yFXJ30Nu8nu%2fbsj5LiEKJkus%3d>
> seems to maybe suggest something different, however. Like perhaps that the
> client id of the RP/client that made the authentication request could, in
> some totally unspecified circumstance, be the value of the azp claim and
> that the aud would not identify that client as an intended recipient. Am I
> misinterpreting things? I hope so because that seems like it'd be fragile
> from an interop perspective and is certainly more cumbersome for general
> JWT libraries to support.
>
>
>
>
> from http://tools.ietf.org/html/rfc7519#section-4.1.3
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgVDJXRprGpK9ESVc5UcfRhoeVyqF4FqAreai1hKE%2b8%3d>
>
>  4.1.3.  "aud" (Audience) Claim
>
>    The "aud" (audience) claim identifies the recipients that the JWT is
>    intended for.  Each principal intended to process the JWT MUST
>    identify itself with a value in the audience claim.  If the principal
>    processing the claim does not identify itself with a value in the
>    "aud" claim when this claim is present, then the JWT MUST be
>    rejected.  In the general case, the "aud" value is an array of case-
>    sensitive strings, each containing a StringOrURI value.  In the
>    special case when the JWT has one audience, the "aud" value MAY be a
>    single case-sensitive string containing a StringOrURI value.  The
>    interpretation of audience values is generally application specific.
>    Use of this claim is OPTIONAL.
>
>
> from http://openid.net/specs/openid-connect-core-1_0.html#IDToken
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d>
>
>   ...
>
>   aud
>
> REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain
> the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY
> also contain identifiers for other audiences. In the general case, the aud
> value is an array of case sensitive strings. In the common special case
> when there is one audience, the aud value MAY be a single case sensitive
> string.
>
>   ...
>
>   azp
>
> OPTIONAL. Authorized party - the party to which the ID Token was issued.
> If present, it MUST contain the OAuth 2.0 Client ID of this party. This
> Claim is only needed when the ID Token has a single audience value and that
> audience is different than the authorized party. It MAY be included even
> when the authorized party is the same as the sole audience. The azp value
> is a case sensitive string containing a StringOrURI value.
>
>   ...
>
> from
> http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDTokenValidation&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ko0MzMkFxNMQmWPYs%2fPYGgMvPE2m%2bhuj4vIUBIwyz1M%3d>
>
>   Clients MUST validate the ID Token in the Token Response in the
> following manner:
>
> ...
> 4. If the ID Token contains multiple audiences, the Client SHOULD verify
> that an azp Claim is present.
> ...
> 5. If an azp (authorized party) Claim is present, the Client SHOULD verify
> that its client_id is the Claim Value.
> ...
> 8 If the JWT alg Header Parameter uses a MAC based algorithm such as
> HS256, HS384, or HS512, the octets of the UTF-8 representation of the
> client_secret corresponding to the client_id contained in the aud
> (audience) Claim are used as the key to validate the signature. For MAC
> based algorithms, the behavior is unspecified if the aud is multi-valued or
> if an azp value is present that is different than the aud value.
> The current time MUST be before the time represented by the exp Claim.
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150811/ae8c2b8c/attachment.html>