[Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect

[John Bradley]

From what I understand of Mike's proposal.

He is proposing that the client also use information in the access token to determine what resources it can send the token to.

This is a separate issue from the protected resource determining if it is the intended audience of the token.

Perhaps we can discuss it on today's call.

John

}On 2011-11-14, at 4:06 AM, Anthony Nadalin wrote:

> > I am ok with RECOMMENDing that these audience to be encoded  in the access_token itself, but would like to let the implementors have  choices on it
>  
> Not sure what you mean by encoded in the access_token, I assume you mean that there is a aud_restriction claim in the token, not that the token is encoded somehow that the receiving parties can decode?
>  
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net]On Behalf Of Nat Sakimura
> Sent: Thursday, November 10, 2011 5:04 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect
>  
> Hi. 
>  
> Currently, as it turns out in OpenID Connect, the way to audience restrict 
> the response of a resource endpoint is to encrypt the response 
> using the key of the intended client. The server has to keep track of 
> to whom the access_token was issued, i.e., client audience restriction, 
> and use the registration information of that client to find out the relevant key. 
>  
> By doing so, even if the request comes from a rogue party who phished the 
> legitimate client, the rogue party cannot read the response, so it is secure. 
>  
> As to the resource endpoint audience restriction is concerned, 
> it is done implicitly in the sense that as the access_token is opaque, 
> only the intended endpoint can actually interprete and validate it. 
> This is how the resource endpoint audience restriction is done 
> in OAuth 2.0 as I understand. 
>  
> As it is written right now, how to record both client and resource endpoint 
> audience restriction is an implementation detail. 
> I think it should remain implementation detail, but 
> it is worthwhile to note that somehow the audience restriction MUST be done. 
> I am ok with RECOMMENDing that these audience to be encoded 
> in the access_token itself, but would like to let the implementors have 
> choices on it. 
>  
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>  
> _______________________________________________
> 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/20111114/03f979b0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111114/03f979b0/attachment.p7s>