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

John Bradley ve7jtb at ve7jtb.com
Fri Oct 25 19:40:04 UTC 2013


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 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#IDTokenValidation contains 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131025/b4cfc835/attachment.html>


More information about the Openid-specs-ab mailing list