Best wishes,
-- Mike
From: Justin Richer [mailto:jric...@mit.edu<mailto:jric...@mit.edu>]
Sent: Tuesday, July 07, 2015 4:47 PM
To: Mike Jones
Cc: Brian Campbell; mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Token C
>>> thinking of the Token Exchange requests as signed requests to the Token
>>> Endpoint, just like Nat’s draft makes signed requests to the
>>> Authorization Endpoint, is probably a good unifying mental framework for
>>> all of us to consider applying to this
t;>
> >>Now, a question for the working group… What should the security
> >>token type values for access token and refresh token be? Two
> >>different choices seem to make sense.
> >>
> >>(1) Use the values “access_token” and “refresh_t
Agree Sergey. That line of thinking is largely why
https://tools.ietf.org/html/draft-campbell-oauth-sts utilizes normal OAuth
client authentication.
On Wed, Jul 8, 2015 at 3:26 AM, Sergey Beryozkin
wrote:
>
> On 08/07/15 01:41, Mike Jones wrote:
>
>> [...] That’s why the WG draft uses a JWT as
probably a good unifying mental framework for all of us to consider
> applying to this problem space.
>
>
>
> Best
> wishes,
>
> -- Mike
>
>
>
e values for access token and refresh token be? Two
>>different choices seem to make sense.
>>
>>(1) Use the values “access_token” and “refresh_token”, which are
>>used in RFC 6749 token response values.
>>
>>(2) Define new URNs for this usage, such as
>>urn:ietf:params:oauth:token-type:access-t
...@mit.edu]
*Sent:* Tuesday, July 07, 2015 4:47 PM
*To:* Mike Jones
*Cc:* Brian Campbell;
*Subject:* Re: [OAUTH-WG] Token Chaining Use Case
This approach is not a good fit for my use cases, and it’s still not
OAuth-y at all. It requires a specially-formed security assertion on
the way in, which the
,
-- Mike
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Tuesday, July 07, 2015 4:47 PM
To: Mike Jones
Cc: Brian Campbell;
Subject: Re: [OAUTH-WG] Token Chaining Use Case
This approach is not a good fit for my use cases, and it’s
I’m not sure how Brian’s approach solves the basic generic token exchange use
case that we have
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 7, 2015 4:47 PM
To: Mike Jones
Cc:
Subject: Re: [OAUTH-WG] Token Chaining Use Case
This approach is not a
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Thursday, March 26, 2015 3:15 PM
> To: Justin Richer
> Cc:
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
>
> This kind of token exchange might involve exchanges other than swapping an AT
> for a
ETF 93.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, March 26, 2015 3:15 PM
To: Justin Richer
Cc:
Subject: Re: [OAUTH-WG] Token Chaining Use Case
This kind of token exchange might involve exchanges other than swapping an AT
for another A
Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 refre
) 636-8571
Email:<mailto:donald.cof...@reminetworks.com>
donald.cof...@reminetworks.com
From: Bill Mills [mailto:wmills_92...@yahoo.com]
Sent: Thursday, March 26, 2015 6:04 PM
To: Bill Mills; Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token C
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
sing Suite EDunwoody, GA 30338-8221 Phone:
(949) 636-8571Email: donald.cof...@reminetworks.com From: Bill Mills
[mailto:wmills_92...@yahoo.com]
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining
t; Cc: "Phil Hunt" , oauth@ietf.org
> Sent: Thursday, March 26, 2015 6:29:41 PM
> Subject: RE: [OAUTH-WG] Token Chaining Use Case
>
> Pedro,
>
> Although the registry could be changed to support the new type format, how is
> that any different than adding a new grant_ty
ot;Bill Mills"
> To: "Donald F. Coffin" , "Phil Hunt"
>
> Cc: oauth@ietf.org
> Sent: Thursday, March 26, 2015 6:13:05 PM
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
>
> The RS calling back to the AS won't be confused, the token it gets
Mills"
> To: "Donald F. Coffin" , "Phil Hunt"
>
> Cc: oauth@ietf.org
> Sent: Thursday, March 26, 2015 6:13:05 PM
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
>
> The RS calling back to the AS won't be confused, the token it gets would be
ks.com
From: Bill Mills [mailto:wmills_92...@yahoo.com]
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case
The RS calling back to the AS won't be confused, the token it gets would be
i
: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc:
Subject: Re: [OAUTH-WG] Token Chaining Use Case +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
ks.com
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc:
Subject: Re: [OAUTH-WG] Token Chaining Use Case
+1. We all have to change production code when non final specs evolve.
I particularly don't see this as a valid argument at t
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
Original message ----
> From: Bill Mills
> Date: 03/26/2015 2:24 PM (GMT-06:00)
> To: Justin Richer , ""
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
>
> So why can't the access tokne simply be re-used as a refresh token? Why
> would it need
om my phone /
>
>
> Original message ----
> From: Bill Mills
> Date: 03/26/2015 2:24 PM (GMT-06:00)
> To: Justin Richer , ""
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
>
> So why can't the access tokne simply be re-used as a refresh
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
: 03/26/2015 2:24 PM (GMT-06:00)
To: Justin Richer , ""
Subject: Re: [OAUTH-WG] Token Chaining Use Case
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 Riche
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
phone /
Original message
From: Bill Mills
Date: 03/26/2015 2:24 PM (GMT-06:00)
To: Justin Richer , ""
Subject: Re: [OAUTH-WG] Token Chaining Use Case
So why can't the access tokne simply be re-used as a refresh token? Why would
it need a new grant type
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
30 matches
Mail list logo
