Hannes Tschofenig has requested publication of draft-ietf-oauth-spop-10 as
Proposed Standard on behalf of the OAUTH working group.
Please verify the document's state at
http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
___
OAuth mailing list
OAut
AS already has the problem of checking requested scopes, this doesn't change
that.
In fact an AS could issue a new "refresh token" in return for the presented one
(which is the user/app AT) that's limited to be used by the RS as a client.
If one of the things we want is the ability to have the AS
Bill,
Thanks for the clarification.
How do you propose the AS deal with the following RFC6749 Section 6. Refreshing
an Access Token requirement?
Scope
OPTIONAL. The scope of the access request as described by Section 3.3. The
requested scope MUST NOT include any scope not originall
This kind of token exchange might involve exchanges other than swapping an
AT for another AT (and downscoping it). It might be an AT for a structured
JWT specifically targeted at one of the the particular services that the
original RS needs to call. Or an AT might be exchanged for a SAML assertion
Again, I don't think requiring a call out to an internal token reissuer is a
general solution. That said...
The RS calls the token endpoint treating the AT as a refresh token in all cases
and using the refresh_token grant type. Desired scope is specified by the RS.
It's not in spec if there
Hey Donald,
I see your point. And yes, they are no really different.
However, I think this is pretty much about refreshing tokens. I understand that
in this case the refresh token is not presented by its owner but someone
downstream. But you are kind of refreshing a previously issued token. And
Pedro,
Although the registry could be changed to support the new type format, how is
that any different than adding a new grant_type, such as grant_type=token_swap
or grant_type=swap?
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Crossing Suite E
Dunwoody, GA 30338
Couldn't be used a specific type of refresh_token ? Instead of using
grant_type=refresh_token use a
grant_type=urn:ietf:params:oauth:grant_type:redelegate (or something else) as
an extension to refresh token flow ?
Regards.
Pedro Igor
- Original Message -
> From: "Bill Mills"
> To: "D
Bill,
Can you clarify your thoughts on the following:
* What AS endpoint does the RS call and how does it present the AT he
received?
* What is the grant_type value the RS use in the above endpoint request?
* What does the AS do if the AT was issued by another
The RS calling back to the AS won't be confused, the token it gets would be
it's refresh token. I don't see any reason why the AS can't be smart enough to
know that a token that looks like an access token it issued is usable as a
refresh token for limited purposes or downscoping.
On Th
-1
Although Justin’s point might be a bit pre-mature as far as a standards
discussion, the more critical reason IMHO is calling the AS’s /Token endpoint
with a grant_type of “refresh_token” but providing an issued AT rather than an
issued refresh_token (RT) will definitely create a backward
Requiring a round trip to the AS is going to have a huge headwind for
implementation in high performance environments.
I think we need to pursue something like what Phil is talking about where the
intermediary server has it's own credential or authority.
On Thursday, March 26, 2015 1:25
See below
Phil
> On Mar 26, 2015, at 15:15, Justin Richer wrote:
>
> Your service layout will determine whether or not each bit calls the same AS
> that issued the original token, since you can easily do it across boundaries
> if your AS takes in cross domain tokens. That’s another benefit of
+1. We all have to change production code when non final specs evolve.
I particularly don't see this as a valid argument at the start of a standards
discussion.
Phil
> On Mar 26, 2015, at 15:13, Bill Mills wrote:
>
> By definition an access token is becoming a form of refresh token.The
Not really, because it’s not refreshing access. It’s getting access in the
context of a separate access token, which wasn’t issued to it. The mechanism is
similar to a refresh token but that’s it.
— Justin
> On Mar 26, 2015, at 3:13 PM, Bill Mills wrote:
>
> By definition an access token is
Your service layout will determine whether or not each bit calls the same AS
that issued the original token, since you can easily do it across boundaries if
your AS takes in cross domain tokens. That’s another benefit of having it be a
generic token swap, you can build it out using the same mech
By definition an access token is becoming a form of refresh token. The
"because my implementation didn't do it that way" isn't convincing me.
On Thursday, March 26, 2015 12:44 PM, Justin Richer
wrote:
Because many implementations (including mine which does support my old token
What if A calls be with it’s own authorization token (server token ST1) and
passes AT1 in another header e.g. on-behalf-of.
You save a call and can still check the scope downstream. Further, service B
and C can each check whether ST1 and ST2 had the right to wield AT1 even when
AT1’s POP proof
Because many implementations (including mine which does support my old token
chaining draft) treat access tokens and refresh tokens separately in terms of
data store and structure. Additionally, the refresh token is tied to the client
and presented by the client. But in this case it's some
So why can't the access tokne simply be re-used as a refresh token? Why would
it need a new grant type at all?
On Thursday, March 26, 2015 11:31 AM, Justin Richer
wrote:
As requested after last night’s informal meeting, here is the token chaining
use case that I want to see repr
As requested after last night’s informal meeting, here is the token chaining
use case that I want to see represented in the token swap draft.
[ Client ] -> [ A ] -> [ B ] -> [ C ]
An OAuth client gets an access token AT1, just like it always would, with
scopes [A, B, C] in order to call ser
21 matches
Mail list logo
