,
-- Mike
*From:*Justin Richer [mailto:jric...@mit.edu]
*Sent:* Tuesday, July 07, 2015 4:47 PM
*To:* Mike Jones
*Cc:* Brian Campbell; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Token Chaining Use Case
This approach is not a good fit for my use cases, and it’s still
...@mit.edu]
*Sent:* Tuesday, July 07, 2015 4:47 PM
*To:* Mike Jones
*Cc:* Brian Campbell; oauth@ietf.org
*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
,
-- Mike
*From:* Justin Richer [mailto:jric...@mit.edu]
*Sent:* Tuesday, July 07, 2015 4:47 PM
*To:* Mike Jones
*Cc:* Brian Campbell; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Token Chaining Use Case
This approach is not a good fit for my use cases
] Token Chaining Use Case
There is a lot in common, yes. Fundamentally we're working to address the same
needs, which should lead to some commonality. But I was also trying to be
conciliatory in the work I did and make a good faith effort at establishing
some commonality from which collaborative
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 sberyoz...@gmail.com
wrote:
On 08/07/15 01:41, Mike Jones wrote:
[...] That’s why the WG
,
-- Mike
*From:*Justin Richer [mailto:jric...@mit.edu]
*Sent:* Tuesday, July 07, 2015 4:47 PM
*To:* Mike Jones
*Cc:* Brian Campbell; oauth@ietf.org
*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
:* Tuesday, July 07, 2015 4:47 PM
*To:* Mike Jones
*Cc:* Brian Campbell; oauth@ietf.org
*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
: [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 client must understand and generate. I still can’t take an arbitrary token
I’ve been handed by someone
.
-- 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: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case
This kind of token exchange might involve exchanges other than swapping an AT
for another
: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case
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
,
-- Mike
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Tuesday, July 07, 2015 4:47 PM
To: Mike Jones
Cc: Brian Campbell; oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case
This approach is not a good fit for my use
/
Original message
From: Bill Mills wmills_92...@yahoo.com
Date: 03/26/2015 2:24 PM (GMT-06:00)
To: Justin Richer jric...@mit.edu, oauth@ietf.org oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case
So why can't the access tokne simply be re-used as a refresh token
See below
Phil
On Mar 26, 2015, at 15:15, Justin Richer jric...@mit.edu 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
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
-06:00)
To: Justin Richer jric...@mit.edu, oauth@ietf.org oauth@ietf.org
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
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 jric...@mit.edu
wrote:
As requested after last night’s informal meeting, here is the token chaining
use case that I
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
wmills_92...@yahoo.com
Cc: Phil Hunt phil.h...@oracle.com, 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_type
: donald.cof...@reminetworks.com From: Phil Hunt
[mailto:phil.h...@oracle.com]
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: oauth@ietf.org
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
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
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
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
...@oracle.com]
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: oauth@ietf.org
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
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
it's refresh token. I don't
wmills_92...@yahoo.com
To: Donald F. Coffin donald.cof...@reminetworks.com, Phil Hunt
phil.h...@oracle.com
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
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: oauth@ietf.org
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
...@yahoo.com
To: Donald F. Coffin donald.cof...@reminetworks.com, Phil Hunt
phil.h...@oracle.com
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
it's
; 'Phil 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 refresh_token
28 matches
Mail list logo
