[Openid-specs-ab] Questions about multiple audiences for ID Tokens using MAC algorithms

Tim Bray tbray at textuality.com
Mon Oct 28 20:18:25 UTC 2013


Hold on, you said “mulitple 'aud' values”.  In the same ID Token... is that
allowed?!?


On Mon, Oct 28, 2013 at 12:52 PM, George Fletcher <gffletch at aol.com> wrote:

>  Thanks for the clarifications! What about combining what John and Mike
> said into something like...
>
> ID Tokens containing a 'azp' value SHOULD be signed with an asymmetric
> key. The verification steps for ID Tokens signed with a MAC based algorithm
> containing either mulitple 'aud' values and/or an 'azp' value are
> unspecified and out-of-scope for this document.
>
> Thanks,
> George
>
>  On 10/28/13 2:33 PM, John Bradley wrote:
>
> I think the point of signing is so that the audience can verify it.  In
> the case that the azp is different from the audience the azp the token
> should be treated as opaque to the azp party.
> I appreciate that clients may do content sniffing as they do in SAML in
> some cases.
>
>  In general it is best for the AS to use a asymmetric signature all the
> time to get around these issues.
>
>  The simple rule for symmetric keys is you is the one shared with the
> audience,  the use of azp should not impact that.
> If that is to confusing I am OK with saying tokens containing azp MUST be
> signed with a asymmetric key and forget this corner case.
>
>  I don't consider a token with azp one that necessarily has multiple
> audiences.  It is possible to have two or more audiences where one is also
> the azp, that defiantly needs asymmetric signing.
>
>  John B.
>
>   On Oct 25, 2013, at 6:04 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>   John, your reply didn’t answer the question about which Client ID would
> be used if the “aud” and “azp” values refer to different parties.  I could
> see arguments for either.****
>
> Partly for that reason, I’m prone to have us say that the behavior is
> unspecified if a MAC algorithm is used and the “aud” is multi-valued or if
> an “azp” value is present that is different than the “aud” value.****
>
> That would leave the door open to specify it later, but avoids us making
> important decisions about use cases we have no experience with now.****
>
>                                                                 -- Mike***
> *
>
>  *From:* Torsten Lodderstedt [mailto:torsten at lodderstedt.net<torsten at lodderstedt.net>
> ]
> *Sent:* Friday, October 25, 2013 1:59 PM
> *To:* John Bradley
> *Cc:* Mike Jones; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Questions about multiple audiences for
> ID Tokens using MAC algorithms****
>  ** **
>  ** **
>
>
> Am 25.10.2013 um 21:40 schrieb John Bradley <ve7jtb at ve7jtb.com>:****
>
> A token with a single audience that is different from the AZP is fine to
> integrity protect with mac as long as there the AZP is not expected to
> validate the token.  ****
>
>  ** **
>  I think this is only possible for id tokens issued via code grant type,
> right?****
>
>
> ****
>  ** **
>  I personally think symmetric key management argues that it is not
> scalable.  However we should not preclude that use.
>
> Sent from my iPhone****
>
>
> On Oct 24, 2013, at 10:32 PM, Torsten Lodderstedt <torsten at lodderstedt.net>
> wrote:****
>
> Hi all,
>
> MAC as symmetric alg only makes sense (from a security perspective) for
> two parties. I consider sharing a symmetric key among more than two parties
> a bad design. So in my opinion this restriction makes sense.
>
> Wrt 5. Yes, we should tighten it.
>
> Regards,
> Torsten.****
>
>
> Mike Jones <Michael.Jones at microsoft.com> schrieb:****
> http://openid.bitbucket.org/openid-connect-core-1_0.html#IDTokenValidationcontains
> this text that George asked about in his review:****
> 7.  If the alg parameter of the JWT header is 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 theaud (audience)
> Claim are used as the key to validate the signature.Multiple audiences
> are not supported for MAC based algorithms.****
>
>  ****
> George wrote:****
> “Why not? Wouldn't the secret associated with the azp work for the client
> to validate the id_token?  If we want interoperability across the use of
> audience and azp we are going to need to describe how it works in an
> extension document. It is not clear from this spec how it is to work and I
> was on most of the calls:)”****
>
>  ****
> These questions arise:****
> 1.       Does anyone remember the history behind the highlighted
> sentence?  I’m pretty sure that this was written before we had an “azp”
> claim.****
> 2.       If there’s an “azp” claim and an “aud” claim and the values are
> different, which Client Secret would be the right one to use as the key
> value?  (George seems to be suggesting that it’s the one associated with
> the Client ID in the “azp” value.)****
> 3.       If we did want to relax the restriction prohibiting multiple
> audiences, which value would be used for the key?  And would all the
> parties that need to valid the ID Token signature actually have access to
> this value?****
> 4.       Or should we leave the text above as-is for now, and deal with
> this case as an extension later, if a need for it ever comes up?****
> 5.       If we’re not defining how multi-valued audiences would work with
> MAC signatures for now, should we also tighten this be requiring that any
> “azp” value that is include have the same value as the single-valued
> audience value?****
>
>  ****
>                                                             -- Mike****
>
>  ****
>
> ------------------------------
>
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://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
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131028/1f04d041/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 80878 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131028/1f04d041/attachment-0001.png>


More information about the Openid-specs-ab mailing list