It sounds like we want to return a list of available access tokens “aud” values from AS config discovery endpoint (and also via oauth-meta too?), doesn’t it?
and RS config discovery endpoint will return acceptable access token “iss” values, a list of every RS endpoints, required scopes per endpoint etc. (it would be another thread though) Thanks, Nov > On Feb 26, 2016, at 13:08, Nat Sakimura <sakim...@gmail.com> wrote: > > I will include the origin in the next rev. > > For http header v.s JSON, shall I bring the JSON back in? > 2016年2月26日(金) 13:05 Manger, James <james.h.man...@team.telstra.com > <mailto:james.h.man...@team.telstra.com>>: > You are right, George, that making the AS track /v2/… or /v3/… in RS paths is > likely to be brittle — but tracking RS web origins is not too onerous. > > > > PoP has some nice security advantages over bearer tokens or passwords. > However, it should still be possible to use the latter fairly safely — but it > does require the issuer of credentials to indicate where they can be used. > > > > -- > > James Manger > > > > > > > > From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of George Fletcher > Sent: Friday, 26 February 2016 2:28 AM > To: Vladimir Dzhuvinov <vladi...@connect2id.com > <mailto:vladi...@connect2id.com>>; oauth@ietf.org <mailto:oauth@ietf.org> > > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > > > That said, I'm not against the AS informing the client that the token can be > used at the MailResource, ContactResource and MessagingResource to help the > client know not to send the token to a BlogResource. However, identifying the > actual endpoint seems overly complex when what is really trying to be > protected is a token from being used where it shouldn't be (which is solved > by Pop) > > Thanks, > George > > On 2/25/16 10:25 AM, George Fletcher wrote: > > Interesting... this is not at all my current experience:) If a RS goes from > v2 of it's API to v3 and that RS uses the current standard of putting a "v2" > or"v3" in it's API path... then a token issued for v2 of the API can not be > sent to v3 of the API, because v3 wasn't wasn't registered/deployed when the > token was issued. > > The constant management of scopes to URI endpoints seems like a complexity > that will quickly get out of hand. > > Thanks, > George > > On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote: > > > > On 25/02/16 09:02, Manger, James wrote: > > I'm concerned that forcing the AS to know about all RS's endpoints that will > accept it's tokens creates a very brittle deployment architecture > The AS is issuing temporary credentials (access_tokens) to clients but > doesn’t know where those credentials will work? That’s broken. > > An AS should absolutely indicate where an access_token can be used. > draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” > (resource URI) values in an HTTP Link header. A better approach would be > including a list of web origins in the token response beside the access_token > field. > +1 > > This will appear more consistent with the current experience, and OAuth does > allow the token response JSON object to be extended with additional members > (as it's done in OpenID Connect already). > > Cheers, > Vladimir > > > > -- > James Manger > > From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of George Fletcher > Sent: Thursday, 25 February 2016 6:17 AM > To: Phil Hunt <phil.h...@oracle.com> <mailto:phil.h...@oracle.com>; Nat > Sakimura <sakim...@gmail.com> <mailto:sakim...@gmail.com> > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> > <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > I'm concerned that forcing the AS to know about all RS's endpoints that will > accept it's tokens creates a very brittle deployment architecture. What if a > RS moves to a new endpoint? All clients would be required to get new tokens > (if I understand correctly). And the RS move would have to coordinate with > the AS to make sure all the timing is perfect in the switch over of endpoints. > > I suspect a common deployment architecture today is that each RS requires one > or more scopes to access it's resources. The client then asks the user to > authorize a token with a requested list of scopes. The client can then send > the token to the appropriate RS endpoint. The RS will not authorize access > unless the token has the required scopes. > > If the concern is that the client may accidentally send the token to a "bad" > RS which will then replay the token, then I'd rather use a PoP mechanism > because the point is that you want to ensure the correct client is presenting > the token. Trying to ensure the client doesn't send the token to the wrong > endpoint seems fraught with problems. > > Thanks, > George > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
