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>:
> 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] *On Behalf Of *George > Fletcher > *Sent:* Friday, 26 February 2016 2:28 AM > *To:* Vladimir Dzhuvinov <vladi...@connect2id.com>; 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 <oauth-boun...@ietf.org>] On > Behalf Of George Fletcher > > Sent: Thursday, 25 February 2016 6:17 AM > > To: Phil Hunt <phil.h...@oracle.com> <phil.h...@oracle.com>; Nat Sakimura > <sakim...@gmail.com> <sakim...@gmail.com> > > Cc: <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> <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 > > 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 > > > _______________________________________________ > 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
