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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Proof-of-Possession Key Semantics for JSON Web Tokens
(JWTs)
Authors : Michael B.
The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition
(impersonation) feature as this enables an account to impersonate another
account for the purpose of providing access to resources. In a typical
scenario, the impersonating account would be a service account assigned to a
I keep providing links to MS documentation that leads one to a different
conclusion for WIF.
https://msdn.microsoft.com/en-us/library/ee748487.aspx
https://msdn.microsoft.com/en-us/library/ee748487.aspx and
https://msdn.microsoft.com/en-us/library/ee517269.aspx
An ActAs RST element indicates
I think the original reasoning was sound, but the fact that so many remain
confused is good reason to go to new vocab.
We could still have clarifying text that impersonate/composite is xxx and yyy
in kerberos etc.
Phil
On Jul 6, 2015, at 13:43, Anthony Nadalin tony...@microsoft.com wrote:
A natural usage of act-as or impersonation
http://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 text below from
It would surprise me if on-behalf-of and act-as were reversed with respect
WS-Trust, because the explanations of the terms came directly from WS-Trust
1.4. I also think the chances of us reducing confusion by inventing new
terminology, rather than adding to it, would not be in our favor. :-/
The claim “azp” has already been registered by OpenID Connect Core at
http://www.iana.org/assignments/jwt/jwt.xhtml and so cannot be re-registered.
Given that I believe the intended semantics are the same, please cite the
existing definition, rather than repeating it.
Mike,
I have pointed this out several times. I understand that you disagree.
The WS-Trust spec is not as clear as it could be. I included the MSDN note
explaining how WIF interprets it.
https://msdn.microsoft.com/en-us/library/ee748487.aspx
Given that there seems to be differing opinions
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 to adjourn in order to go to the bar (okay, and dinner too -
Fair enough, Brian. For clarity, my sense of the action items is that I agreed
to do those actions based on feedback at the ad-hoc meeting and then people
would review the result – not that everything would be “done” after taking
those actions. I’ll still plan to act on that feedback.
I’d be
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Request by JWS ver.1.0 for OAuth 2.0
Authors : Nat Sakimura
The invalid_request_uri parameter has already been registered at
http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml by
OpenID Connect Core, and so cannot be re-registered.
invalid_request_format looks like a duplicate of the already registered
invalid_request_object
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Proof Key for Code Exchange by OAuth Public Clients
Authors : Nat Sakimura
+1 for this. Let's learn from the mistakes of the past instead of
repeating them. We've always done it this way is a really, really poor
reason for doing something.
-- Justin
On 7/6/2015 5:20 PM, Phil Hunt wrote:
I think the original reasoning was sound, but the fact that so many
remain
What is written in
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 and
the text that describes the Windows Kerberos support for Protocol Transition
and Constrained Delegation are in alignment not sure what make you think they
are not.
If you are trying to describe
Sorry Mike,
I was looking at an earlier version that had them reversed. I think the
wording can be improved but the composite vs delegation semantic is correct now.
However Tony now seems to disagree with that. I am going to walk away slowly
and let you sort out his last post:)
We can
That doesn't even make sense.
On Mon, Jul 6, 2015 at 3:56 PM, Anthony Nadalin tony...@microsoft.com
wrote:
What is written in
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
and the text that describes the Windows Kerberos support for Protocol
Transition and
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Token Exchange
Authors : Michael B. Jones
Anthony
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-14: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Section 5.2 lists the possible errors the authorization server can return
for an access token request. In the list is invalid_scope, which as I
understand it, can only be returned for a password or
client_credentials grant, since scope is not a parameter of an
authorization_code grant.
Because of
I submitted version -02 of draft-ietf-oauth-pop-architecture to update
references.
Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
___
OAuth
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Request by JWS ver.1.0 for OAuth 2.0
Authors : Nat Sakimura
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Proof-of-Possession (PoP) Security
Architecture
Authors : Phil Hunt
26 matches
Mail list logo
