[OAUTH-WG] invalid_scope in access token request

[Aaron Parecki]

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 this, I believe the phrase "or exceeds the scope granted by the
resource owner." is unnecessary, since there is no initial grant by the
resource owner. Am I reading this correctly, or is there some situation I
am not thinking of? Thanks!


Aaron Parecki
aaronparecki.com
@aaronpk 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

[Barry Leiba]

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/



--
COMMENT:
--

Version -14 resolves my DISCUSS (and also some of my non-blocking
comments).  Thanks very much for considering these and working with me on
them!

  =
My comment about the IANA Considerations remains.  While it's
non-blocking, I still hope you will accept the change I suggest:

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please shift
the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated expert(s)
keep track of.  Also, please give more instructions to the DEs about what
they should consider when they're evaluating a request (for example,
should they approve all requests, or are there criteria they should
apply?).

For the first, here's a text change that I suggest we move toward for
this sort of thing:

OLD


NEW
   Additional code_challenge_method types for use with the authorization
   endpoint are registered using the Specification Required policy
   [RFC5226], which includes review of the request by one or more
   Designated Experts.  The DEs will ensure there is at least a two-week
   review of the request on the oauth-ext-rev...@ietf.org mailing list,
   and that any discussion on that list converges before they respond to
   the request.  To allow for the allocation of values prior to
   publication, the Designated Expert(s) may approve registration once
   they are satisfied that an acceptable specification will be
published.

   Discussion on the oauth-ext-rev...@ietf.org mailing list should use
   an appropriate subject, such as "Request for PKCE
   code_challenge_method: example").

   The Designated Expert(s) should consider the discussion on the
   mailing list, as well as <> when evaluating
   registration requests.  Denials should include an explanation
   and, if applicable, suggestions as to how to make the request
   successful.
END

  =
-- Section 7.2 --
I find the first first paragraph confusingly worded, and after discussion
with the author I suggest this:

NEW
Clients MUST NOT downgrade to "plain" after trying the S256 method.
Because servers are required to support S256, an error when S256 is
presented can only mean that the server does not support PKCE at all.
Otherwise, such an error could be indicative of a MITM attacker trying
a downgrade attack.
END

  =
Finally, there is this comment, which is not a big deal and you should
proceed as you think best:

-- Section 2 --
There is no real distinction between STRING and ASCII(STRING), because
STRING is already defined to be ASCII.  Using "ASCII(xxx)" only adds
clutter, and a suggest removing it.

So, for example, that would result in changes such as this:

OLD
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
NEW
BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge
END


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Justin Richer]

+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 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 > wrote:


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 web application or the computer account of a 
web server. The impersonated account would be a user account 
requiring access to resources (e.g. data in an SQL database) via a 
web application. In this scenario, SQL server would be accessed by 
the impersonating (service account) account, however access would be 
under the context of the impersonated (user) account.


WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained 
Delegation feature, which lets you limit the back-end services for 
which a front-end service can request tickets on behalf of another 
user. “OnBehalfOf”  allows a selected services on a server can be 
granted for access by the impersonating account, whilst other 
services on the same server, or services on other servers are denied 
for access.


Maybe someone can summarize why they think the text for ActAs and 
OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I 
have not seen a clear explanation other than John saying that Brian 
knows and Brian saying John knows.


Our usage and use cases are based upon the deployed services of 
WS-Trust and Kerberos support in Windows (workstation and server) and 
Xbox.


*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian 
Campbell

*Sent:* Monday, July 6, 2015 11:29 AM
*To:* Mike Jones >

*Cc:* oauth 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 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 - but mostly beer).


The impression about reversal of terms, I think, comes from the text 
in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
which hurts my head a little every-time I read it but does seems to 
confuse things. The MSDN link 
 John gave is 
much more to the point than WS-Trust (I don't believe WS-Trust can be 
pointed to as a model of clarity).  In the draft I wrote, I tried to 
take Mike's text and clarify a distinction between impersonation and 
delegation with 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 
and then also be very explicit about act-as vs. on-behalf-of in the 
parameter definitions at 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in 
a manor that was consistent with WS-Trust and the MSDN explanation. I 
could see value in breaking with that shaky legacy and using new 
terms too. But I get the point of trying to keep with the old also 
and potential for even more confusing by using new terms.


I wrote draft-campbell-oauth-sts last year in response to the call 
for adoption of jones-oauth-token-exchange (thread from the archive 
). 
Though I didn't try and stand in the way and indicated a willingness 
to collaborate on things. With the expectation, of course, that the 
details would differ from the -00s and -01s as work progressed. Folks 
seemed generally amenable to that 
 
at the time but little has happened since then.


Phil's earlier point about the priory of this getting pushed down has 
some truth to it. But I still believe it's something that can provide 
a lot of value in standardizing, if we do so in a reasonable way.




On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:


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. :-/

FYI, the action items outstanding from our ad-hoc meeting on this
draft in Dallas are:
  - Allowing security types other than JWT to also be used as the
act_as 

[OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

[internet-drafts]

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
  John Bradley
  Naveen Agarwal
Filename: draft-ietf-oauth-spop-14.txt
Pages   : 20
Date: 2015-07-06

Abstract:
   OAuth 2.0 public clients utilizing the Authorization Code Grant are
   susceptible to the authorization code interception attack.  This
   specification describes the attack as well as a technique to mitigate
   against the threat through the use of Proof Key for Code Exchange
   (PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spop-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-02.txt

[internet-drafts]

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 Nadalin
Filename: draft-ietf-oauth-token-exchange-02.txt
Pages   : 10
Date: 2015-07-06

Abstract:
   This specification defines how to request and obtain Security Tokens
   from OAuth Authorization Servers, including enabling one party to act
   on behalf of another or enabling one party to delegate authority to
   another.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Brian Campbell]

That doesn't even make sense.

On Mon, Jul 6, 2015 at 3:56 PM, Anthony Nadalin 
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 Constrained Delegation are in alignment not sure what make
> you think they are not.
>
>
>
> If you are trying to describe different features than Windows Kerberos 
> Protocol
> Transition/Constrained Delegation that then I would agree that the text
> may not be correct but then again it would not be describing the Windows
> Kerberos Protocol Transition/Constrained Delegation. The way you have the
> text describes different set use case then what the feature of
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
> describes.
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Monday, July 6, 2015 2:33 PM
> *To:* Anthony Nadalin 
> *Cc:* Mike Jones ; oauth 
>
> *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case
>
>
>
> A natural usage of act-as or impersonation
> 
> would suggest, to many people anyway, that the way you just used the terms
> is reversed. The bold text below from
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
> uses 'impersonates' and "on-behalf-of" contrary to what you just wrote
> about Windows Kerb. That's where the assertion that the draft has them
> reversed from de facto usage in WS-Trust. Those semantics are not only one
> open issue that needs to be resolved, however, even if they occupy most of
> the discussion.
>
>
>
> 1.3.  On-Behalf-Of vs. Impersonation Semantics
>
>When principal A acts on behalf of principal B, A is given all the
>rights that B has within some defined rights context.  Whereas, *with*
> *   on-behalf-of semantics, principal A still has its own identity*
> *   separate from B and it is explicitly understood that while B may have*
> *   delegated its rights to A, any actions taken are being taken by A and*
> *   not B. In a sense, A is an agent for B.*
>
>On-behalf-of semantics are therefore different than impersonation
>semantics, with which it is sometimes confused.  *When principal A*
> *   impersonates principal B, then in so far as any entity receiving*
> *   Claims is concerned, they are actually dealing with B. *It is true
>that some members of the identity system might have awareness that
>impersonation is going on but it is not a requirement.  For all
>intents and purposes, when A is acting for B, A is B.
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin 
> wrote:
>
>  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 web application or the computer account of a web server. The impersonated
> account would be a user account requiring access to resources (e.g. data in
> an SQL database) via a web application. In this scenario, SQL server would
> be accessed by the impersonating (service account) account, however access
> would be under the context of the impersonated (user) account.
>
>
>
> WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation
> feature, which lets you limit the back-end services for which a front-end
> service can request tickets on behalf of another user. “OnBehalfOf”  allows
> a selected services on a server can be granted for access by the
> impersonating account, whilst other services on the same server, or
> services on other servers are denied for access.
>
>
>
> Maybe someone can summarize why they think the text for ActAs and
> OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have
> not seen a clear explanation other than John saying that Brian knows and
> Brian saying John knows.
>
>
>
> Our usage and use cases are based upon the deployed services of WS-Trust
> and Kerberos support in Windows (workstation and server) and Xbox.
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, July 6, 2015 11:29 AM
> *To:* Mike Jones 
> *Cc:* 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 and decided to adjourn in order to go to the bar (okay, and dinner too -
> but mostly beer).
>
> The impression about reversal of terms, I think, comes from the text in
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
> which hurts my head a little every-time

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[John Bradley]

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 discuss further in Prague.

John B.

> On Jul 6, 2015, at 3:48 PM, Mike Jones  wrote:
> 
> 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 glad to sit down with you and others in Prague, Brian, to work out how 
> to make sure your use cases are covered and the draft is as clear as it can 
> be, given its somewhat esoteric subject matter.  Now that JWT and JOSE and 
> the OAuth Assertions specs are done and several others are nearly done, 
> getting back to this is a priority for me.
>  
> Cheers,
> -- 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 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 - but 
> mostly beer).
> 
> The impression about reversal of terms, I think, comes from the text in 
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
>  
> which hurts my head a little every-time I read it but does seems to confuse 
> things. The MSDN link 
>  John gave is much 
> more to the point than WS-Trust (I don't believe WS-Trust can be pointed to 
> as a model of clarity).  In the draft I wrote, I tried to take Mike's text 
> and clarify a distinction between impersonation and delegation with 
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 
>  and 
> then also be very explicit about act-as vs. on-behalf-of in the parameter 
> definitions at 
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 
>  in a 
> manor that was consistent with WS-Trust and the MSDN explanation. I could see 
> value in breaking with that shaky legacy and using new terms too. But I get 
> the point of trying to keep with the old also and potential for even more 
> confusing by using new terms. 
> 
> I wrote draft-campbell-oauth-sts last year in response to the call for 
> adoption of jones-oauth-token-exchange (thread from the archive 
> ). Though 
> I didn't try and stand in the way and indicated a willingness to collaborate 
> on things. With the expectation, of course, that the details would differ 
> from the -00s and -01s as work progressed. Folks seemed generally amenable to 
> that  at 
> the time but little has happened since then.
> 
> Phil's earlier point about the priory of this getting pushed down has some 
> truth to it. But I still believe it's something that can provide a lot of 
> value in standardizing, if we do so in a reasonable way.
>  
> 
> 
> 
> 
>  
> 
>  
> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones  > wrote:
> 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. :-/
> 
> FYI, the action items outstanding from our ad-hoc meeting on this draft in 
> Dallas are:
>   - Allowing security types other than JWT to also be used as the act_as and 
> on_behalf_of request values.
>   - Further integrating the mechanism into the existing OAuth ecosystem - 
> allowing use of access tokens or refresh tokens when appropriate.
> 
> I plan to do the first today.  The second is probably more than I'll get done 
> today before the submission cutoff.  I agree with John that it would be 
> useful to have discussions on this in Prague on the best way to achieve this 
> further integration.  I'll plan to come into the Prague meeting with a 
> concrete proposal for review.
> 
> Best 

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Anthony Nadalin]

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 different features than Windows Kerberos Protocol 
Transition/Constrained Delegation that then I would agree that the text may not 
be correct but then again it would not be describing the Windows Kerberos 
Protocol Transition/Constrained Delegation. The way you have the text describes 
different set use case then what the feature of  
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
describes.

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, July 6, 2015 2:33 PM
To: Anthony Nadalin 
Cc: Mike Jones ; oauth 
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

A natural usage of act-as or 
impersonation
 would suggest, to many people anyway, that the way you just used the terms is 
reversed. The bold text below from 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 
'impersonates' and "on-behalf-of" contrary to what you just wrote about Windows 
Kerb. That's where the assertion that the draft has them reversed from de facto 
usage in WS-Trust. Those semantics are not only one open issue that needs to be 
resolved, however, even if they occupy most of the discussion.

1.3.  On-Behalf-Of vs. Impersonation Semantics

   When principal A acts on behalf of principal B, A is given all the
   rights that B has within some defined rights context.  Whereas, with
   on-behalf-of semantics, principal A still has its own identity
   separate from B and it is explicitly understood that while B may have
   delegated its rights to A, any actions taken are being taken by A and
   not B. In a sense, A is an agent for B.

   On-behalf-of semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  When principal A
   impersonates principal B, then in so far as any entity receiving
   Claims is concerned, they are actually dealing with B. It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is B.





On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
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 
web application or the computer account of a web server. The impersonated 
account would be a user account requiring access to resources (e.g. data in an 
SQL database) via a web application. In this scenario, SQL server would be 
accessed by the impersonating (service account) account, however access would 
be under the context of the impersonated (user) account.

WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation 
feature, which lets you limit the back-end services for which a front-end 
service can request tickets on behalf of another user. “OnBehalfOf”  allows a 
selected services on a server can be granted for access by the impersonating 
account, whilst other services on the same server, or services on other servers 
are denied for access.

Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in 
WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear 
explanation other than John saying that Brian knows and Brian saying John knows.

Our usage and use cases are based upon the deployed services of WS-Trust and 
Kerberos support in Windows (workstation and server) and Xbox.

From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: oauth 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 
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 - but mostly 
beer).
The impression about reversal of terms, I think, comes from the text in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
which hurts my head a little every-time I read it but does seems to confuse 
things. The MSDN link 
John gave is much more to the point than WS-Trust (I don't believe WS-Trust can 

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Brian Campbell]

A natural usage of act-as or impersonation

would suggest, to many people anyway, that the way you just used the terms
is reversed. The bold text below from
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
uses 'impersonates' and "on-behalf-of" contrary to what you just wrote
about Windows Kerb. That's where the assertion that the draft has them
reversed from de facto usage in WS-Trust. Those semantics are not only one
open issue that needs to be resolved, however, even if they occupy most of
the discussion.

1.3.  On-Behalf-Of vs. Impersonation Semantics

   When principal A acts on behalf of principal B, A is given all the
   rights that B has within some defined rights context.  Whereas, *with*
*   on-behalf-of semantics, principal A still has its own identity*
*   separate from B and it is explicitly understood that while B may have*
*   delegated its rights to A, any actions taken are being taken by A and*
*   not B. In a sense, A is an agent for B.*

   On-behalf-of semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  *When principal A*
*   impersonates principal B, then in so far as any entity receiving*
*   Claims is concerned, they are actually dealing with B. *It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is B.







On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin 
wrote:

>  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 web application or the computer account of a web server. The impersonated
> account would be a user account requiring access to resources (e.g. data in
> an SQL database) via a web application. In this scenario, SQL server would
> be accessed by the impersonating (service account) account, however access
> would be under the context of the impersonated (user) account.
>
>
>
> WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation
> feature, which lets you limit the back-end services for which a front-end
> service can request tickets on behalf of another user. “OnBehalfOf”  allows
> a selected services on a server can be granted for access by the
> impersonating account, whilst other services on the same server, or
> services on other servers are denied for access.
>
>
>
> Maybe someone can summarize why they think the text for ActAs and
> OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have
> not seen a clear explanation other than John saying that Brian knows and
> Brian saying John knows.
>
>
>
> Our usage and use cases are based upon the deployed services of WS-Trust
> and Kerberos support in Windows (workstation and server) and Xbox.
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, July 6, 2015 11:29 AM
> *To:* Mike Jones 
> *Cc:* 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 and decided to adjourn in order to go to the bar (okay, and dinner too -
> but mostly beer).
>
> The impression about reversal of terms, I think, comes from the text in
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
> which hurts my head a little every-time I read it but does seems to confuse
> things. The MSDN link
>  John gave is
> much more to the point than WS-Trust (I don't believe WS-Trust can be
> pointed to as a model of clarity).  In the draft I wrote, I tried to take
> Mike's text and clarify a distinction between impersonation and delegation
> with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3
> and then also be very explicit about act-as vs. on-behalf-of in the
> parameter definitions at
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a
> manor that was consistent with WS-Trust and the MSDN explanation. I could
> see value in breaking with that shaky legacy and using new terms too. But I
> get the point of trying to keep with the old also and potential for even
> more confusing by using new terms.
>
> I wrote draft-campbell-oauth-sts last year in response to the call for
> adoption of jones-oauth-token-exchange (thread from the archive
> ).
> Though I didn't try and stand in the way and indicat

[OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-03.txt

[internet-drafts]

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. Jones
  John Bradley
  Hannes Tschofenig
Filename: draft-ietf-oauth-proof-of-possession-03.txt
Pages   : 13
Date: 2015-07-06

Abstract:
   This specification defines how to express a declaration in a JSON Web
   Token (JWT) that the presenter of the JWT possesses a particular key
   and that the recipient can cryptographically confirm proof-of-
   possession of the key by the presenter.  This property is also
   sometimes described as the presenter being a holder-of-key.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Phil Hunt]

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  wrote:
> 
> 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 
> web application or the computer account of a web server. The impersonated 
> account would be a user account requiring access to resources (e.g. data in 
> an SQL database) via a web application. In this scenario, SQL server would be 
> accessed by the impersonating (service account) account, however access would 
> be under the context of the impersonated (user) account.
>  
> WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation 
> feature, which lets you limit the back-end services for which a front-end 
> service can request tickets on behalf of another user. “OnBehalfOf”  allows a 
> selected services on a server can be granted for access by the impersonating 
> account, whilst other services on the same server, or services on other 
> servers are denied for access.
>  
> Maybe someone can summarize why they think the text for ActAs and OnBehalfOf 
> in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a 
> clear explanation other than John saying that Brian knows and Brian saying 
> John knows.
>  
> Our usage and use cases are based upon the deployed services of WS-Trust and 
> Kerberos support in Windows (workstation and server) and Xbox.
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Monday, July 6, 2015 11:29 AM
> To: Mike Jones 
> Cc: 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 
> and decided to adjourn in order to go to the bar (okay, and dinner too - but 
> mostly beer).
> 
> The impression about reversal of terms, I think, comes from the text in 
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
> which hurts my head a little every-time I read it but does seems to confuse 
> things. The MSDN link John gave is much more to the point than WS-Trust (I 
> don't believe WS-Trust can be pointed to as a model of clarity).  In the 
> draft I wrote, I tried to take Mike's text and clarify a distinction between 
> impersonation and delegation with 
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then 
> also be very explicit about act-as vs. on-behalf-of in the parameter 
> definitions at 
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor 
> that was consistent with WS-Trust and the MSDN explanation. I could see value 
> in breaking with that shaky legacy and using new terms too. But I get the 
> point of trying to keep with the old also and potential for even more 
> confusing by using new terms.
> 
> I wrote draft-campbell-oauth-sts last year in response to the call for 
> adoption of jones-oauth-token-exchange (thread from the archive). Though I 
> didn't try and stand in the way and indicated a willingness to collaborate on 
> things. With the expectation, of course, that the details would differ from 
> the -00s and -01s as work progressed. Folks seemed generally amenable to that 
> at the time but little has happened since then.
> 
> Phil's earlier point about the priory of this getting pushed down has some 
> truth to it. But I still believe it's something that can provide a lot of 
> value in standardizing, if we do so in a reasonable way.
>  
> 
> 
> 
> 
>  
> 
>  
> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones  
> wrote:
> 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. :-/
> 
> FYI, the action items outstanding from our ad-hoc meeting on this draft in 
> Dallas are:
>   - Allowing security types other than JWT to also be used as the act_as and 
> on_behalf_of request values.
>   - Further integrating the mechanism into the existing OAuth ecosystem - 
> allowing use of access tokens or refresh tokens when appropriate.
> 
> I plan to do the first today.  The second is probably more than I'll get done 
> today before the submission cutoff.  I agree with John that it would be 
> useful to have discussions on this in Prague on the best way to achieve this 
> further

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[John Bradley]

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 
 and 
https://msdn.microsoft.com/en-us/library/ee517269.aspx
An ActAs RST element indicates that the requestor wants a token that contains 
claims about two distinct entities: the requestor, and an external entity 
represented by the token in the ActAs element.

An OnBehalfOf RST element indicates that the requestor wants a token that 
contains claims only about one entity: the external entity represented by the 
token in the OnBehalfOf element.

That reflects my understanding that prior to WS-Trust 1.4 OnBehalfOf was 
impersonation and in WS-Trust 1.4 was added to provide the composite assertion.

The JBOS docs and examples are also consistent with this 
https://docs.jboss.org/author/display/JBWS/ActAs+WS-Trust+Scenario
Or these: 
https://thilinamb.wordpress.com/2009/08/21/identity-delegation-in-ws-trust-1-4/

http://blogs.msdn.com/b/alikl/archive/2011/03/15/windows-identity-foundation-wif-the-difference-between-actas-and-onbehalfof.aspx?Redirected=true

https://www.netiq.com/documentation/netiqaccessmanager4/identityserverhelp/data/ws-trust_usecases.html

Given that you were one of the authors, you are as close to authoritative as 
one could get.   

However as far as I can tell there is some confusion that needs to be resolved. 

I agree we need the functionality of the two, and I don’t really care what they 
are called as long as we are not confusing developers.


John B.

> On Jul 6, 2015, at 5:43 PM, Anthony Nadalin  wrote:
> 
> 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 
> web application or the computer account of a web server. The impersonated 
> account would be a user account requiring access to resources (e.g. data in 
> an SQL database) via a web application. In this scenario, SQL server would be 
> accessed by the impersonating (service account) account, however access would 
> be under the context of the impersonated (user) account.
>  
> WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation 
> feature, which lets you limit the back-end services for which a front-end 
> service can request tickets on behalf of another user. “OnBehalfOf”  allows a 
> selected services on a server can be granted for access by the impersonating 
> account, whilst other services on the same server, or services on other 
> servers are denied for access.
>  
> Maybe someone can summarize why they think the text for ActAs and OnBehalfOf 
> in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a 
> clear explanation other than John saying that Brian knows and Brian saying 
> John knows.  <>
>  
> Our usage and use cases are based upon the deployed services of WS-Trust and 
> Kerberos support in Windows (workstation and server) and Xbox.
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Monday, July 6, 2015 11:29 AM
> To: Mike Jones 
> Cc: 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 
> and decided to adjourn in order to go to the bar (okay, and dinner too - but 
> mostly beer).
> 
> The impression about reversal of terms, I think, comes from the text in 
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
>  
> which hurts my head a little every-time I read it but does seems to confuse 
> things. The MSDN link 
>  John gave is much 
> more to the point than WS-Trust (I don't believe WS-Trust can be pointed to 
> as a model of clarity).  In the draft I wrote, I tried to take Mike's text 
> and clarify a distinction between impersonation and delegation with 
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 
>  and 
> then also be very explicit about act-as vs. on-behalf-of in the parameter 
> definitions at 
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 
>  in a 
> manor that was consistent with WS-Trust and the MSDN explanation. I could see 
> value in breaking with that shaky legacy and using new terms too. But I get 
> the point of trying to keep with the old also and poten

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Anthony Nadalin]

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 
web application or the computer account of a web server. The impersonated 
account would be a user account requiring access to resources (e.g. data in an 
SQL database) via a web application. In this scenario, SQL server would be 
accessed by the impersonating (service account) account, however access would 
be under the context of the impersonated (user) account.

WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation 
feature, which lets you limit the back-end services for which a front-end 
service can request tickets on behalf of another user. “OnBehalfOf”  allows a 
selected services on a server can be granted for access by the impersonating 
account, whilst other services on the same server, or services on other servers 
are denied for access.

Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in 
WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear 
explanation other than John saying that Brian knows and Brian saying John knows.

Our usage and use cases are based upon the deployed services of WS-Trust and 
Kerberos support in Windows (workstation and server) and Xbox.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones 
Cc: 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 and 
decided to adjourn in order to go to the bar (okay, and dinner too - but mostly 
beer).
The impression about reversal of terms, I think, comes from the text in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
which hurts my head a little every-time I read it but does seems to confuse 
things. The MSDN link 
John gave is much more to the point than WS-Trust (I don't believe WS-Trust can 
be pointed to as a model of clarity).  In the draft I wrote, I tried to take 
Mike's text and clarify a distinction between impersonation and delegation with 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then 
also be very explicit about act-as vs. on-behalf-of in the parameter 
definitions at 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor 
that was consistent with WS-Trust and the MSDN explanation. I could see value 
in breaking with that shaky legacy and using new terms too. But I get the point 
of trying to keep with the old also and potential for even more confusing by 
using new terms.
I wrote draft-campbell-oauth-sts last year in response to the call for adoption 
of jones-oauth-token-exchange (thread from the 
archive). 
Though I didn't try and stand in the way and indicated a willingness to 
collaborate on things. With the expectation, of course, that the details would 
differ from the -00s and -01s as work progressed. Folks seemed generally 
amenable to 
that at the 
time but little has happened since then.
Phil's earlier point about the priory of this getting pushed down has some 
truth to it. But I still believe it's something that can provide a lot of value 
in standardizing, if we do so in a reasonable way.





On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
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. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in 
Dallas are:
  - Allowing security types other than JWT to also be used as the act_as and 
on_behalf_of request values.
  - Further integrating the mechanism into the existing OAuth ecosystem - 
allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second is probably more than I'll get done 
today before the submission cutoff.  I agree with John that it would be useful 
to have discussions on this in Prague on the best way to achieve this further 
integration.  I'll plan to come into the Prague meeting with a concrete 
proposal for review.

Best wishes,
-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@i

[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-04.txt

[internet-drafts]

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
  John Bradley
Filename: draft-ietf-oauth-jwsreq-04.txt
Pages   : 9
Date: 2015-07-06

Abstract:
   The authorization request in OAuth 2.0 utilizes query parameter
   serialization.  This specification defines the authorization request
   using JWT serialization.  The request is sent through "request"
   parameter or by reference through "request_uri" parameter that points
   to the JWT, allowing the request to be optionally signed and
   encrypted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Mike Jones]

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 glad to sit down with you and others in Prague, Brian, to work out how 
to make sure your use cases are covered and the draft is as clear as it can be, 
given its somewhat esoteric subject matter.  Now that JWT and JOSE and the 
OAuth Assertions specs are done and several others are nearly done, getting 
back to this is a priority for me.

Cheers,
-- 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 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 - but mostly 
beer).
The impression about reversal of terms, I think, comes from the text in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
which hurts my head a little every-time I read it but does seems to confuse 
things. The MSDN link 
John gave is much more to the point than WS-Trust (I don't believe WS-Trust can 
be pointed to as a model of clarity).  In the draft I wrote, I tried to take 
Mike's text and clarify a distinction between impersonation and delegation with 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then 
also be very explicit about act-as vs. on-behalf-of in the parameter 
definitions at 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor 
that was consistent with WS-Trust and the MSDN explanation. I could see value 
in breaking with that shaky legacy and using new terms too. But I get the point 
of trying to keep with the old also and potential for even more confusing by 
using new terms.
I wrote draft-campbell-oauth-sts last year in response to the call for adoption 
of jones-oauth-token-exchange (thread from the 
archive). 
Though I didn't try and stand in the way and indicated a willingness to 
collaborate on things. With the expectation, of course, that the details would 
differ from the -00s and -01s as work progressed. Folks seemed generally 
amenable to 
that at the 
time but little has happened since then.
Phil's earlier point about the priory of this getting pushed down has some 
truth to it. But I still believe it's something that can provide a lot of value 
in standardizing, if we do so in a reasonable way.





On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
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. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in 
Dallas are:
  - Allowing security types other than JWT to also be used as the act_as and 
on_behalf_of request values.
  - Further integrating the mechanism into the existing OAuth ecosystem - 
allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second is probably more than I'll get done 
today before the submission cutoff.  I agree with John that it would be useful 
to have discussions on this in Prague on the best way to achieve this further 
integration.  I'll plan to come into the Prague meeting with a concrete 
proposal for review.

Best wishes,
-- Mike

-Original Message-
From: 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 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 WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short 
explanation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had O

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[John Bradley]

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 on the semantics beyond just 
me, can we agree that the terms are not as clear as one would hope?

I may be wrong, but I suspect that I am not the only one.  

We can discuss it at the F2F.


John B.
> On Jul 6, 2015, at 1:33 PM, Mike Jones  wrote:
> 
> 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. :-/
> 
> FYI, the action items outstanding from our ad-hoc meeting on this draft in 
> Dallas are:
>  - Allowing security types other than JWT to also be used as the act_as and 
> on_behalf_of request values.
>  - Further integrating the mechanism into the existing OAuth ecosystem - 
> allowing use of access tokens or refresh tokens when appropriate.
> 
> I plan to do the first today.  The second is probably more than I'll get done 
> today before the submission cutoff.  I agree with John that it would be 
> useful to have discussions on this in Prague on the best way to achieve this 
> further integration.  I'll plan to come into the Prague meeting with a 
> concrete proposal for review.
> 
>   Best wishes,
>   -- Mike
> 
> -Original Message-
> From: 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 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 WS-Trust 1.4.
> see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short 
> explanation.
> 
> I think Brian is closer in explaining it.
> 
> In fairness because WS-Trust originally only had On-Behalf-Of the naming and 
> what people put in tokens is a bit muddled in many implementations.
> I think many times it is how WIF implemented it that people copied.
> 
> It may be better to have new terms that are clear such as impersonation and 
> composite.
> 
> The WG needs to decide if this is going to be an entirely new endpoint, free 
> of the Token endpoint semantics.   There are plusses and minuses to both 
> options.
> 
> Also while it is nice to be pure and talk about abstract security tokens, it 
> would be good to give some guidance on what a composite security token would 
> look like for interoperability.
> 
> There are also issues around how this would work with proof of possession 
> security tokens, both as input and output.
> 
> Perhaps we can make some progress on this in Prague.
> 
> John B.
> 
> 
> 
> 
>> On Jul 6, 2015, at 11:04 AM, Brian Campbell  
>> wrote:
>> 
>> 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 chaining type 
>> cases that Justin's draft covers. 
>> 
>> Specifying a security_token_type of the returned token is just a way of 
>> providing more info to the client about the token (i.e. is this a JWT or a 
>> SAML token or something else) via a URI. It's not always needed but in STS 
>> style cases the tokens are not always opaque to the client and the parameter 
>> just provides info about the returned token.  
>> 
>> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin  
>> wrote:
>> 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 can cover a 
>> draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) 
>> property being an original client token but not 100% sure given 
>> draft-richer-oauth-chain-00 covers a specific case.
>> 
>> One thing I'm not sure about is what is the purpose of specifying a 
>> security_token_type of the returned access token
>> 
>> Thanks, Sergey
>> 
>> On 01/07/15 15:59, Brian Campbell wrote:
>> 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 sa

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Brian Campbell]

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 -
but mostly beer).

The impression about reversal of terms, I think, comes from the text in
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
which hurts my head a little every-time I read it but does seems to confuse
things. The MSDN link
 John gave is much
more to the point than WS-Trust (I don't believe WS-Trust can be pointed to
as a model of clarity).  In the draft I wrote, I tried to take Mike's text
and clarify a distinction between impersonation and delegation with
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and
then also be very explicit about act-as vs. on-behalf-of in the parameter
definitions at
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a
manor that was consistent with WS-Trust and the MSDN explanation. I could
see value in breaking with that shaky legacy and using new terms too. But I
get the point of trying to keep with the old also and potential for even
more confusing by using new terms.

I wrote draft-campbell-oauth-sts last year in response to the call for
adoption of jones-oauth-token-exchange (thread from the archive
).
Though I didn't try and stand in the way and indicated a willingness to
collaborate on things. With the expectation, of course, that the details
would differ from the -00s and -01s as work progressed. Folks seemed generally
amenable to that
 at the
time but little has happened since then.

Phil's earlier point about the priory of this getting pushed down has some
truth to it. But I still believe it's something that can provide a lot of
value in standardizing, if we do so in a reasonable way.








On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones 
wrote:

> 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. :-/
>
> FYI, the action items outstanding from our ad-hoc meeting on this draft in
> Dallas are:
>   - Allowing security types other than JWT to also be used as the act_as
> and on_behalf_of request values.
>   - Further integrating the mechanism into the existing OAuth ecosystem -
> allowing use of access tokens or refresh tokens when appropriate.
>
> I plan to do the first today.  The second is probably more than I'll get
> done today before the submission cutoff.  I agree with John that it would
> be useful to have discussions on this in Prague on the best way to achieve
> this further integration.  I'll plan to come into the Prague meeting with a
> concrete proposal for review.
>
> Best wishes,
> -- Mike
>
> -Original Message-
> From: 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 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 WS-Trust 1.4.
> see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short
> explanation.
>
> I think Brian is closer in explaining it.
>
> In fairness because WS-Trust originally only had On-Behalf-Of the naming
> and what people put in tokens is a bit muddled in many implementations.
> I think many times it is how WIF implemented it that people copied.
>
> It may be better to have new terms that are clear such as impersonation
> and composite.
>
> The WG needs to decide if this is going to be an entirely new endpoint,
> free of the Token endpoint semantics.   There are plusses and minuses to
> both options.
>
> Also while it is nice to be pure and talk about abstract security tokens,
> it would be good to give some guidance on what a composite security token
> would look like for interoperability.
>
> There are also issues around how this would work with proof of possession
> security tokens, both as input and output.
>
> Perhaps we can make some progress on this in Prague.
>
> John B.
>
>
>
>
> > On Jul 6, 2015, at 11:04 AM, Brian Campbell 
> wrote:
> >
> > Thanks Sergey,
> >
> > The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0
> and thus 

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-rjwtprof-04.txt

[Mike Jones]

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.

Best wishes,
-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Sunday, June 28, 2015 8:53 PM
To: oauth; oauth-cha...@tools.ietf.org
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-rjwtprof-04.txt

Hi

Kepeng and I rev'ed this discussion draft which describes sender confirmation 
method
using JWT against a resource.

It is pretty short.

Derek and Hannes,

We would like to have sometime in the OAuth WG session to discuss about it.
I hope you can allocate a bit of time for it.

Best,

Nat

-- Forwarded message --
From: mailto:internet-dra...@ietf.org>>
Date: 2015-06-29 12:47 GMT+09:00
Subject: New Version Notification for draft-sakimura-oauth-rjwtprof-04.txt
To: Kepeng Li mailto:kepeng@alibaba-inc.com>>, 
Nat Sakimura mailto:sakim...@gmail.com>>



A new version of I-D, draft-sakimura-oauth-rjwtprof-04.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-rjwtprof
Revision:   04
Title:  Sender Constrained JWT for OAuth 2.0
Document date:  2015-06-29
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-rjwtprof-04.txt
Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/
Htmlized:   https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-rjwtprof-04

Abstract:
   This discussion document describes a method to indicate a sender
   constraint within JWT.  It could potentially be incorporated into
   POPS spec [POPS].





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-03.txt

[Mike Jones]

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 parameter.  Please change to use the existing error name.

Please also try to reconcile invalid_request_params with existing JWS request 
usage already specified by OpenID Connect Core.

Thanks,
-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Monday, July 06, 2015 8:12 AM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-03.txt


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
  John Bradley
Filename: draft-ietf-oauth-jwsreq-03.txt
Pages   : 10
Date: 2015-07-06

Abstract:
   The authorization request in OAuth 2.0 utilizes query parameter
   serialization.  This specification defines the authorization request
   using JWT serialization.  The request is sent through "request"
   parameter or by reference through "request_uri" parameter that points
   to the JWT, allowing the request to be optionally signed and
   encrypted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-03


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Phil Hunt]

I agree. Changing the terms helps get us out of the perpetual confusion around 
ActAs and OnBehalfOf.

I like the idea of “impersonation” and “composite” instead.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

> On Jul 6, 2015, at 8:12 AM, John Bradley  wrote:
> 
> 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 WS-Trust 1.4.
> see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short 
> explanation.
> 
> I think Brian is closer in explaining it.
> 
> In fairness because WS-Trust originally only had On-Behalf-Of the naming and 
> what people put in tokens is a bit muddled in many implementations.
> I think many times it is how WIF implemented it that people copied.
> 
> It may be better to have new terms that are clear such as impersonation and 
> composite.
> 
> The WG needs to decide if this is going to be an entirely new endpoint, free 
> of the Token endpoint semantics.   There are plusses and minuses to both 
> options.
> 
> Also while it is nice to be pure and talk about abstract security tokens, it 
> would be good to give some guidance on what a composite security token would 
> look like for interoperability.
> 
> There are also issues around how this would work with proof of possession 
> security tokens, both as input and output.
> 
> Perhaps we can make some progress on this in Prague.
> 
> John B.
> 
> 
> 
> 
>> On Jul 6, 2015, at 11:04 AM, Brian Campbell  
>> wrote:
>> 
>> 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 chaining type 
>> cases that Justin's draft covers. 
>> 
>> Specifying a security_token_type of the returned token is just a way of 
>> providing more info to the client about the token (i.e. is this a JWT or a 
>> SAML token or something else) via a URI. It's not always needed but in STS 
>> style cases the tokens are not always opaque to the client and the parameter 
>> just provides info about the returned token.  
>> 
>> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin  
>> wrote:
>> 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 can cover a 
>> draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) 
>> property being an original client token but not 100% sure given 
>> draft-richer-oauth-chain-00 covers a specific case.
>> 
>> One thing I'm not sure about is what is the purpose of specifying a 
>> security_token_type of the returned access token
>> 
>> Thanks, Sergey
>> 
>> On 01/07/15 15:59, Brian Campbell wrote:
>> 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 attempt to simplify things and express what I envisioned as an OAuth
>> based token exchange framework. Though it likely only muddied the waters :)
>> 
>> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > > wrote:
>> 
>>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 not sure in the draft-richer-oauth-chain-00 about is
>>on behalf of whose entity RS1 will be acting once it starts
>>accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
>>Client), or may be it is On Behalf Of RO + Act As Client ? The last
>>one seems most logical to me...
>> 
>>Thanks, Sergey
>> 
>> 
>>On 01/07/15 13:18, Justin Richer wrote:
>> 
>>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 the document. Years ago, I proposed an OAuth-based
>>token swap
>>mechanism:
>> 
>

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Mike Jones]

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. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in 
Dallas are:
  - Allowing security types other than JWT to also be used as the act_as and 
on_behalf_of request values.
  - Further integrating the mechanism into the existing OAuth ecosystem - 
allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second is probably more than I'll get done 
today before the submission cutoff.  I agree with John that it would be useful 
to have discussions on this in Prague on the best way to achieve this further 
integration.  I'll plan to come into the Prague meeting with a concrete 
proposal for review.

Best wishes,
-- Mike

-Original Message-
From: 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 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 WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short 
explanation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had On-Behalf-Of the naming and 
what people put in tokens is a bit muddled in many implementations.
I think many times it is how WIF implemented it that people copied.

It may be better to have new terms that are clear such as impersonation and 
composite.

The WG needs to decide if this is going to be an entirely new endpoint, free of 
the Token endpoint semantics.   There are plusses and minuses to both options.

Also while it is nice to be pure and talk about abstract security tokens, it 
would be good to give some guidance on what a composite security token would 
look like for interoperability.

There are also issues around how this would work with proof of possession 
security tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.



 
> On Jul 6, 2015, at 11:04 AM, Brian Campbell  
> wrote:
> 
> 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 chaining type cases that 
> Justin's draft covers. 
> 
> Specifying a security_token_type of the returned token is just a way of 
> providing more info to the client about the token (i.e. is this a JWT or a 
> SAML token or something else) via a URI. It's not always needed but in STS 
> style cases the tokens are not always opaque to the client and the parameter 
> just provides info about the returned token.  
> 
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin  wrote:
> 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 can cover a 
> draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) 
> property being an original client token but not 100% sure given 
> draft-richer-oauth-chain-00 covers a specific case.
> 
> One thing I'm not sure about is what is the purpose of specifying a 
> security_token_type of the returned access token
> 
> Thanks, Sergey
> 
> On 01/07/15 15:59, Brian Campbell wrote:
> 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 attempt to simplify things and express what I envisioned as an 
> OAuth based token exchange framework. Though it likely only muddied 
> the waters :)
> 
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin  > wrote:
> 
> 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...
> 
> 

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[John Bradley]

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 WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short 
explanation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had On-Behalf-Of the naming and 
what people put in tokens is a bit muddled in many implementations.
I think many times it is how WIF implemented it that people copied.

It may be better to have new terms that are clear such as impersonation and 
composite.

The WG needs to decide if this is going to be an entirely new endpoint, free of 
the Token endpoint semantics.   There are plusses and minuses to both options.

Also while it is nice to be pure and talk about abstract security tokens, it 
would be good to give some guidance on what a composite security token would 
look like for interoperability.

There are also issues around how this would work with proof of possession 
security tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.



 
> On Jul 6, 2015, at 11:04 AM, Brian Campbell  
> wrote:
> 
> 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 chaining type cases that 
> Justin's draft covers. 
> 
> Specifying a security_token_type of the returned token is just a way of 
> providing more info to the client about the token (i.e. is this a JWT or a 
> SAML token or something else) via a URI. It's not always needed but in STS 
> style cases the tokens are not always opaque to the client and the parameter 
> just provides info about the returned token.  
> 
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin  wrote:
> 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 can cover a 
> draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) 
> property being an original client token but not 100% sure given 
> draft-richer-oauth-chain-00 covers a specific case.
> 
> One thing I'm not sure about is what is the purpose of specifying a 
> security_token_type of the returned access token
> 
> Thanks, Sergey
> 
> On 01/07/15 15:59, Brian Campbell wrote:
> 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 attempt to simplify things and express what I envisioned as an OAuth
> based token exchange framework. Though it likely only muddied the waters :)
> 
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin  > wrote:
> 
> 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 not sure in the draft-richer-oauth-chain-00 about is
> on behalf of whose entity RS1 will be acting once it starts
> accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
> Client), or may be it is On Behalf Of RO + Act As Client ? The last
> one seems most logical to me...
> 
> Thanks, Sergey
> 
> 
> On 01/07/15 13:18, Justin Richer wrote:
> 
> 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 the document. Years ago, I proposed an OAuth-based
> token swap
> mechanism:
> 
> https://tools.ietf.org/html/draft-richer-oauth-chain-00
> 
> This works without defining semantics of the tokens themselves, just
> like the rest of OAuth. I've proposed to the authors of the current
> draft that it should incorporate both semantic (using JWT) and
> syntactic
> (using a simple token-agnostic grant) token swap mechanisms, and
> that
>   

[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-03.txt

[internet-drafts]

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
  John Bradley
Filename: draft-ietf-oauth-jwsreq-03.txt
Pages   : 10
Date: 2015-07-06

Abstract:
   The authorization request in OAuth 2.0 utilizes query parameter
   serialization.  This specification defines the authorization request
   using JWT serialization.  The request is sent through "request"
   parameter or by reference through "request_uri" parameter that points
   to the JWT, allowing the request to be optionally signed and
   encrypted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft-ietf-oauth-pop-architecture-02

[Hannes Tschofenig]

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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-02.txt

[internet-drafts]

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
  Justin Richer
  William Mills
  Prateek Mishra
  Hannes Tschofenig
Filename: draft-ietf-oauth-pop-architecture-02.txt
Pages   : 21
Date: 2015-07-06

Abstract:
   The OAuth 2.0 bearer token specification, as defined in RFC 6750,
   allows any party in possession of a bearer token (a "bearer") to get
   access to the associated resources (without demonstrating possession
   of a cryptographic key).  To prevent misuse, bearer tokens must to be
   protected from disclosure in transit and at rest.

   Some scenarios demand additional security protection whereby a client
   needs to demonstrate possession of cryptographic keying material when
   accessing a protected resource.  This document motivates the
   development of the OAuth 2.0 proof-of-possession security mechanism.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Brian Campbell]

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
chaining type cases that Justin's draft covers.

Specifying a security_token_type of the returned token is just a way of
providing more info to the client about the token (i.e. is this a JWT or a
SAML token or something else) via a URI. It's not always needed but in STS
style cases the tokens are not always opaque to the client and the
parameter just provides info about the returned token.

On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin 
wrote:

> 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 can cover a
> draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?)
> property being an original client token but not 100% sure given
> draft-richer-oauth-chain-00 covers a specific case.
>
> One thing I'm not sure about is what is the purpose of specifying a
> security_token_type of the returned access token
>
> Thanks, Sergey
>
> On 01/07/15 15:59, Brian Campbell wrote:
>
>> 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 attempt to simplify things and express what I envisioned as an OAuth
>> based token exchange framework. Though it likely only muddied the waters
>> :)
>>
>> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > > wrote:
>>
>> 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 not sure in the draft-richer-oauth-chain-00 about is
>> on behalf of whose entity RS1 will be acting once it starts
>> accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
>> Client), or may be it is On Behalf Of RO + Act As Client ? The last
>> one seems most logical to me...
>>
>> Thanks, Sergey
>>
>>
>> On 01/07/15 13:18, Justin Richer wrote:
>>
>> 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 the document. Years ago, I proposed an OAuth-based
>> token swap
>> mechanism:
>>
>> https://tools.ietf.org/html/draft-richer-oauth-chain-00
>>
>> This works without defining semantics of the tokens themselves,
>> just
>> like the rest of OAuth. I've proposed to the authors of the
>> current
>> draft that it should incorporate both semantic (using JWT) and
>> syntactic
>> (using a simple token-agnostic grant) token swap mechanisms, and
>> that
>> the two could be easily compatible.
>>
>>-- Justin
>>
>> On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
>>
>> 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...
>>
>> Cheers, Sergey
>>
>>
>> On 30/06/15 13:38, Sergey Beryozkin wrote:
>>
>> 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 semantics, principal A still
>> has its own
>> identity separate from B and it is explicitly understood
>> that while B
>> may have delegated its rights to

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Sergey Beryozkin]

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 can cover a 
draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) 
property being an original client token but not 100% sure given 
draft-richer-oauth-chain-00 covers a specific case.


One thing I'm not sure about is what is the purpose of specifying a 
security_token_type of the returned access token


Thanks, Sergey

On 01/07/15 15:59, Brian Campbell wrote:

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 attempt to simplify things and express what I envisioned as an OAuth
based token exchange framework. Though it likely only muddied the waters :)

On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

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 not sure in the draft-richer-oauth-chain-00 about is
on behalf of whose entity RS1 will be acting once it starts
accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
Client), or may be it is On Behalf Of RO + Act As Client ? The last
one seems most logical to me...

Thanks, Sergey


On 01/07/15 13:18, Justin Richer wrote:

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 the document. Years ago, I proposed an OAuth-based
token swap
mechanism:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

This works without defining semantics of the tokens themselves, just
like the rest of OAuth. I've proposed to the authors of the current
draft that it should incorporate both semantic (using JWT) and
syntactic
(using a simple token-agnostic grant) token swap mechanisms, and
that
the two could be easily compatible.

   -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:

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...

Cheers, Sergey


On 30/06/15 13:38, Sergey Beryozkin wrote:

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 semantics, principal A still
has its own
identity separate from B and it is explicitly understood
that while B
may have delegated its rights to A, any actions taken
are being taken by
A and not B. In a sense, A is an agent for B."

This is a typical case with the authorization code flow
where a client
application acts on-behalf-of the user who authorized
this application ?

Sorry if I'm missing something

Cheers, Sergey
On 25/06/15 22:28, Mike Jones wrote:

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
Biswas
-T (vibiswas - XORIANT CORPORATION at Cisco)
*Sent:* Thursday, June 25, 2015 2:20 PM
*To:* OAuth@ietf.org