[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.
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
> <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.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.png>
More information about the Openid-specs-ab
mailing list