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

George Fletcher gffletch at aol.com
Mon Oct 28 19:52:55 UTC 2013

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.


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 
> <mailto: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 
>> <mailto: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 
>> <mailto: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 <mailto: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
>>     <mailto: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 thealgparameter of the JWT header is a MAC based algorithm
>>     such asHS256,HS384, orHS512, the octets of the UTF-8
>>     representation of theclient_secretcorresponding to
>>     theclient_idcontained 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 list
>>     Openid-specs-ab at lists.openid.net  <mailto: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
>>     <mailto: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

George Fletcher <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131028/365f589f/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/365f589f/attachment-0001.png>

More information about the Openid-specs-ab mailing list