On Feb 26, 2016, at 13:08, Nat Sakimura <sakim...@gmail.com
<mailto: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] 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
