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

Brian Campbell bcampbell at pingidentity.com
Mon Oct 28 17:03:15 UTC 2013


I agree with Mike here. I think the language came from the reasonable
assumption that a shared secret is only shared between two parties. But
what delineates a party and/or how they might use a token isn't totally
clear. I think leaving it unspecified is preferable at this point.


On Fri, Oct 25, 2013 at 3: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]
> *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 the aud(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 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****
>
>
> _______________________________________________
> 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/4d123a3e/attachment.html>


More information about the Openid-specs-ab mailing list