Speaking as someone who is reasonably familiar with Kerberos and the
general concepts involved, I find both Microsoft/Kerberos technology
((constrained delegation/protocol transition) and the ws-trust text
horribly confusing and would recommend against all of the above as
examples of clarity.
I'm just catching up on this tread, but would appreciate an in-room
discussion on this topic that doesn't assume the adopted draft has the
agreed upon approach as I am not reading that there is consensus on that
approach in this thread at all.
Could we see presentations on Mike's draft and
Kathleen,
I agree that Brian’s approach covers the use case that drove my original draft
and effectively subsumes my approach.
My standing contention with the document as it stands is and has always been
that it’s lacking a general syntactical approach and it isn’t very OAuth-y. I
would love
] On Behalf Of Justin Richer
Sent: Tuesday, July 07, 2015 12:52 PM
To: Kathleen Moriarty
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Kathleen,
I agree that Brian’s approach covers the use case that drove my original draft
and effectively subsumes my approach.
My
On Tue, Jul 7, 2015 at 3:43 PM, Kathleen Moriarty
kathleen.moriarty.i...@gmail.com wrote:
I'm just catching up on this tread, but would appreciate an in-room
discussion on this topic that doesn't assume the adopted draft has the
agreed upon approach as I am not reading that there is consensus
Hi Brian
I've read the text, I like it is still pure OAuth2, with few extra
parameters added to the access token request, and a key response
property being 'access_token' as opposed to 'security_access_token' as
in the draft-ietf-oauth-token-exchange-01.
It appears draft-campbell-oauth-sts-01
Thanks Sergey,
The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0
and thus hopefully familiar to developers and easy to understand and
implement (especially from the client side). It's also intended to be
flexible in order to accommodate a variety of use-cases including the
...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones michael.jo...@microsoft.com
Cc: oauth oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting in Dallas like
that suggests some clear
, 2015 11:29 AM
To: Mike Jones michael.jo...@microsoft.com
Cc: oauth oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting in Dallas
like that suggests some clear consensus was reached, which is not at all
: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones michael.jo...@microsoft.com
Cc: oauth oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting
*Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting in Dallas
like that suggests some clear consensus was reached, which is not at all
the case. As I recall, several of us argued past one another for an hour or
so and decided
Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Yes unfortunately we haven’t made any progress on this since accepting Mike’s
first draft.
His proposal is basically for a new endpoint while Brian tired to fit it into
the existing token endpoint.
I think draft-ietf
Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Yes unfortunately we haven’t made any progress on this since accepting Mike’s
first draft.
His proposal is basically for a new endpoint while Brian tired to fit it into
the existing token endpoint.
I think draft-ietf
: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Yes unfortunately we haven’t made any progress on this since accepting
Mike’s first draft.
His proposal
Bradley; oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting in Dallas like
that suggests some clear consensus was reached, which is not at all the case.
As I recall, several of us argued past one another for an hour or so
:* Monday, July 6, 2015 11:29 AM
*To:* Mike Jones michael.jo...@microsoft.com
mailto:michael.jo...@microsoft.com
*Cc:* oauth oauth@ietf.org mailto:oauth@ietf.org
*Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting in
Dallas like
...@microsoft.com; oauth oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
A natural usage of act-as or
impersonationhttp://www.oxforddictionaries.com/us/definition/american_english/impersonate
would suggest, to many people anyway, that the way you just used the terms is
reversed. The bold
,
-- Mike
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, July 06, 2015 11:29 AM
To: Mike Jones
Cc: John Bradley; oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting in Dallas
like that suggests
]
*Sent:* Monday, July 6, 2015 2:33 PM
*To:* Anthony Nadalin tony...@microsoft.com
*Cc:* Mike Jones michael.jo...@microsoft.com; oauth oauth@ietf.org
*Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case
A natural usage of act-as or impersonation
http://www.oxforddictionaries.com/us
Yes unfortunately we haven’t made any progress on this since accepting Mike’s
first draft.
His proposal is basically for a new endpoint while Brian tired to fit it into
the existing token endpoint.
I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs
reversed compared to
] On Behalf Of Justin Richer
Sent: Wednesday, July 1, 2015 5:18 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
As it's written right now, it's a translation of some WS-* concepts into JWT
format. It's not really OAuth-y (since the client has to understand the token
format
Hi Justin
https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier
to read, that I can tell for sure, at least it is obvious why a given
entity (RS1) may want to exchange the current token provided by a client
for a new token. Definitely easily implementable...
One thing I'm
Hmm... perhaps the clue is in the draft title, token-exchange, so may be
it is a case of the given access token (on_behalf_of or act_as
claim) being used to request a new security token. One can only guess
though, does not seem like the authors are keen to answer the newbie
questions...
As it's written right now, it's a translation of some WS-* concepts into
JWT format. It's not really OAuth-y (since the client has to understand
the token format along with everyone else, and according to the authors
the artifacts might not even be OAuth tokens), and that's my main
issue with
One problem, I think, with token exchange is that it can be really simple
(token in and token out) and really complicated (client X wants a token
that says user A is doing something on behalf of user B) at the same time.
I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an
After putting out the original proposal, I am not totally sure we need it. In
many cases we architected around the issue.
https://tools.ietf.org/html/draft-hunt-oauth-chain-01
Question is token swap for cross domain chaining? Shouldn't in domain servers
be acting on internal policy mechanisms?
Hi,
Can you please explain what is the difference between On-Behalf-Of
semantics described in the draft-ietf-oauth-token-exchange-01 and the
implicit On-Behalf-Of semantics a client OAuth2 token possesses ?
For example, draft-ietf-oauth-token-exchange-01 mentions:
Whereas, with on-behalf-of
That's what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is
about.
Cheers,
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vivek
28 matches
Mail list logo
