Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Bill Burke]

My personal opinion is that I'm glad this actor stuff is optional.
For one, none of our users have asked for it and really only do simple
exchanges.  Secondly, the rules for who can exchange what for what is
controlled and defined within our AS.  Makes things a lot simpler on
the client.  I kind of wish the actor stuff would be defined in a
separate specification.  I don't see us implementing it unless users
start asking us to.

On Wed, May 16, 2018 at 6:11 PM, Brian Campbell
 wrote:
> Well, it's already called the "actor claim" so the claimed part is kind of
> implied. And "claimed actor claim" is a rather awkward. Really, all JWT
> claims are "claimed something" but they don't include the "claimed" bit in
> the name. RFC 7519, for example, defines the subject claim but not the
> claimed subject claim.
>
> On Fri, Apr 20, 2018 at 11:38 AM, Denis  wrote:
>>
>> Brian,
>>
>> Eric said: "what is the RP supposed to do when they encounter it? This
>> seems kind of under specified".
>>
>> After reading your explanations below, it looks like the RP can do
>> anything he wants with the "actor".
>> It is a "claimed actor" and, if we keep the concept, it should be called
>> as such. Such a claim cannot be verified.
>> A RP could copy and paste that claim in an audit log. No standard action
>> related to the content of such a claim
>> can be specified in the spec. If the content of a "claimed actor" is used
>> by the RP, it should be only used as an hint
>> and thus be subject to other verifications which are not specified in this
>> specification.
>>
>> Denis
>>
>> Eric, I realize you weren't particularly impressed by my prior statements
>> about the actor claim but, for lack of knowing what else to say, I'm going
>> to kind of repeat what I said about it over in the Phabricator tool and add
>> a little color.
>>
>> The actor claim is intended as a way to express that delegation has
>> happened and identify the entities involved. Access control or other
>> decisions based on it are at the discretion of the consumer of the token
>> based on whatever policy might be in place.
>>
>> There are JWT claims that have concise processing rules with respect to
>> whether or not the JWT can be accepted as valid. Some examples are "aud"
>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519.
>> E.g. if the token is expired or was intended for someone or something else,
>> reject it.
>>
>> And there are JWT claims that appropriately don't specify such processing
>> rules and are solely statements of fact or circumstance. Also from RFC 7519,
>> the "sub" (Subject) and "iat" (Issued At) claims are good examples of such.
>> There might be application or policy specific rules applied to the content
>> of those kinds of claims (e.g. only subjects from a particular organization
>> are able to access tenant specific data or, less realistic but still
>> possible, disallow access for tokens issued outside of regular business
>> hours) but that's all outside the scope of a specification's definition of
>> the claim.
>>
>> The actor claim falls into the latter category. It's a way for the issuer
>> of the token to tell the consumer of the token what is going on. But any
>> action to take (or not) based on that information is at the discretion of
>> the token consumer. I honestly don't know it could be anything more. And
>> don't think it should be.
>>
>> There are two main expected uses of the actor claim (that I'm aware of
>> anyway) that describing here might help. Maybe. One is a human to human
>> delegation case like a customer service rep doing something on behalf of an
>> end user. The subject would be that user and the actor would be the customer
>> service rep. And there wouldn't be any chaining or nesting of the actor. The
>> other case is so called service chaining where a system might exchange a
>> token it receives for a new token that it can use to call a downstream
>> service. And that service in turn might do another exchange to get a new
>> token suitable to call yet another downstream service. And again and so on
>> and turtles all the way. I'm not necessarily endorsing that level of
>> granularity in chaining but it's bound to happen somewhere/sometime. The
>> nested actor claim is able to express that all that has happened with the
>> top level or outermost one being the system currently using the token and
>> prior systems being nested.. What actually gets done with that information
>> is up to the respective systems involved. There might be policy about what
>> system is allowed to call what other system that is enforced. Or maybe the
>> info is just written to an audit log somewhere. Or something else. I don't
>> know. But whatever it is application/deployment/policy dependent and not
>> specifiable by a spec.
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla  wrote:
>>>
>>> Hi folks,
>>>
>>> I've gone over 

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Rob Otto]

+1 to this.

Rob


On Thu, 17 May 2018 at 13:10, Bill Burke  wrote:

> My personal opinion is that I'm glad this actor stuff is optional.
> For one, none of our users have asked for it and really only do simple
> exchanges.  Secondly, the rules for who can exchange what for what is
> controlled and defined within our AS.  Makes things a lot simpler on
> the client.  I kind of wish the actor stuff would be defined in a
> separate specification.  I don't see us implementing it unless users
> start asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell
>  wrote:
> > Well, it's already called the "actor claim" so the claimed part is kind
> of
> > implied. And "claimed actor claim" is a rather awkward. Really, all JWT
> > claims are "claimed something" but they don't include the "claimed" bit
> in
> > the name. RFC 7519, for example, defines the subject claim but not the
> > claimed subject claim.
> >
> > On Fri, Apr 20, 2018 at 11:38 AM, Denis  wrote:
> >>
> >> Brian,
> >>
> >> Eric said: "what is the RP supposed to do when they encounter it? This
> >> seems kind of under specified".
> >>
> >> After reading your explanations below, it looks like the RP can do
> >> anything he wants with the "actor".
> >> It is a "claimed actor" and, if we keep the concept, it should be called
> >> as such. Such a claim cannot be verified.
> >> A RP could copy and paste that claim in an audit log. No standard action
> >> related to the content of such a claim
> >> can be specified in the spec. If the content of a "claimed actor" is
> used
> >> by the RP, it should be only used as an hint
> >> and thus be subject to other verifications which are not specified in
> this
> >> specification.
> >>
> >> Denis
> >>
> >> Eric, I realize you weren't particularly impressed by my prior
> statements
> >> about the actor claim but, for lack of knowing what else to say, I'm
> going
> >> to kind of repeat what I said about it over in the Phabricator tool and
> add
> >> a little color.
> >>
> >> The actor claim is intended as a way to express that delegation has
> >> happened and identify the entities involved. Access control or other
> >> decisions based on it are at the discretion of the consumer of the token
> >> based on whatever policy might be in place.
> >>
> >> There are JWT claims that have concise processing rules with respect to
> >> whether or not the JWT can be accepted as valid. Some examples are "aud"
> >> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC
> 7519.
> >> E.g. if the token is expired or was intended for someone or something
> else,
> >> reject it.
> >>
> >> And there are JWT claims that appropriately don't specify such
> processing
> >> rules and are solely statements of fact or circumstance. Also from RFC
> 7519,
> >> the "sub" (Subject) and "iat" (Issued At) claims are good examples of
> such.
> >> There might be application or policy specific rules applied to the
> content
> >> of those kinds of claims (e.g. only subjects from a particular
> organization
> >> are able to access tenant specific data or, less realistic but still
> >> possible, disallow access for tokens issued outside of regular business
> >> hours) but that's all outside the scope of a specification's definition
> of
> >> the claim.
> >>
> >> The actor claim falls into the latter category. It's a way for the
> issuer
> >> of the token to tell the consumer of the token what is going on. But any
> >> action to take (or not) based on that information is at the discretion
> of
> >> the token consumer. I honestly don't know it could be anything more. And
> >> don't think it should be.
> >>
> >> There are two main expected uses of the actor claim (that I'm aware of
> >> anyway) that describing here might help. Maybe. One is a human to human
> >> delegation case like a customer service rep doing something on behalf
> of an
> >> end user. The subject would be that user and the actor would be the
> customer
> >> service rep. And there wouldn't be any chaining or nesting of the
> actor. The
> >> other case is so called service chaining where a system might exchange a
> >> token it receives for a new token that it can use to call a downstream
> >> service. And that service in turn might do another exchange to get a new
> >> token suitable to call yet another downstream service. And again and so
> on
> >> and turtles all the way. I'm not necessarily endorsing that level of
> >> granularity in chaining but it's bound to happen somewhere/sometime. The
> >> nested actor claim is able to express that all that has happened with
> the
> >> top level or outermost one being the system currently using the token
> and
> >> prior systems being nested.. What actually gets done with that
> information
> >> is up to the respective systems involved. There might be policy about
> what
> >> system is allowed to call what other system that is enforced. Or maybe
> the
> >> info is 

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Mike Jones]

Moving the actor claim to a separate specification would only make things more 
complicated for developers.  There already plenty of OAuth specs.  Needlessly 
adding another one will only make related things harder to find.

Just like in the JWT [RFC 7519] spec itself in which use of all the claims is 
optional, use of the actor claim in this spec.  If you don't need it, don't use 
it.  Just because some won't use it is no better an argument for moving it to a 
different spec than the argument that JWT should have defined each of its 
claims in different specs.  That would have made things harder, not easier.

-- Mike

-Original Message-
From: OAuth  On Behalf Of Bill Burke
Sent: Thursday, May 17, 2018 2:11 PM
To: Brian Campbell 
Cc: oauth 
Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

My personal opinion is that I'm glad this actor stuff is optional.
For one, none of our users have asked for it and really only do simple 
exchanges.  Secondly, the rules for who can exchange what for what is 
controlled and defined within our AS.  Makes things a lot simpler on the 
client.  I kind of wish the actor stuff would be defined in a separate 
specification.  I don't see us implementing it unless users start asking us to.

On Wed, May 16, 2018 at 6:11 PM, Brian Campbell  
wrote:
> Well, it's already called the "actor claim" so the claimed part is 
> kind of implied. And "claimed actor claim" is a rather awkward. 
> Really, all JWT claims are "claimed something" but they don't include 
> the "claimed" bit in the name. RFC 7519, for example, defines the 
> subject claim but not the claimed subject claim.
>
> On Fri, Apr 20, 2018 at 11:38 AM, Denis  wrote:
>>
>> Brian,
>>
>> Eric said: "what is the RP supposed to do when they encounter it? 
>> This seems kind of under specified".
>>
>> After reading your explanations below, it looks like the RP can do 
>> anything he wants with the "actor".
>> It is a "claimed actor" and, if we keep the concept, it should be 
>> called as such. Such a claim cannot be verified.
>> A RP could copy and paste that claim in an audit log. No standard 
>> action related to the content of such a claim can be specified in the 
>> spec. If the content of a "claimed actor" is used by the RP, it 
>> should be only used as an hint and thus be subject to other 
>> verifications which are not specified in this specification.
>>
>> Denis
>>
>> Eric, I realize you weren't particularly impressed by my prior 
>> statements about the actor claim but, for lack of knowing what else 
>> to say, I'm going to kind of repeat what I said about it over in the 
>> Phabricator tool and add a little color.
>>
>> The actor claim is intended as a way to express that delegation has 
>> happened and identify the entities involved. Access control or other 
>> decisions based on it are at the discretion of the consumer of the 
>> token based on whatever policy might be in place.
>>
>> There are JWT claims that have concise processing rules with respect 
>> to whether or not the JWT can be accepted as valid. Some examples are "aud"
>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519.
>> E.g. if the token is expired or was intended for someone or something 
>> else, reject it.
>>
>> And there are JWT claims that appropriately don't specify such 
>> processing rules and are solely statements of fact or circumstance. 
>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims are 
>> good examples of such.
>> There might be application or policy specific rules applied to the 
>> content of those kinds of claims (e.g. only subjects from a 
>> particular organization are able to access tenant specific data or, 
>> less realistic but still possible, disallow access for tokens issued 
>> outside of regular business
>> hours) but that's all outside the scope of a specification's 
>> definition of the claim.
>>
>> The actor claim falls into the latter category. It's a way for the 
>> issuer of the token to tell the consumer of the token what is going 
>> on. But any action to take (or not) based on that information is at 
>> the discretion of the token consumer. I honestly don't know it could 
>> be anything more. And don't think it should be.
>>
>> There are two main expected uses of the actor claim (that I'm aware 
>> of
>> anyway) that describing here might help. Maybe. One is a human to 
>> human delegation case like a customer service rep doing something on 
>> behalf of an end user. The subject would be that user and the actor 
>> would be the customer service rep. And there wouldn't be any chaining 
>> or nesting of the actor. The other case is so called service chaining 
>> where a system might exchange a token it receives for a new token 
>> that it can use to call a downstream service. And that 

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Bill Burke]

This is an honest question: How important is the actor stuff to the
players involved?  Are people going to use it?  IMO, its an edge case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.  I'm quite unfamiliar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.  Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones  wrote:
> Moving the actor claim to a separate specification would only make things 
> more complicated for developers.  There already plenty of OAuth specs.  
> Needlessly adding another one will only make related things harder to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the claims is 
> optional, use of the actor claim in this spec.  If you don't need it, don't 
> use it.  Just because some won't use it is no better an argument for moving 
> it to a different spec than the argument that JWT should have defined each of 
> its claims in different specs.  That would have made things harder, not 
> easier.
>
> -- Mike
>
> -Original Message-
> From: OAuth  On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.
> For one, none of our users have asked for it and really only do simple 
> exchanges.  Secondly, the rules for who can exchange what for what is 
> controlled and defined within our AS.  Makes things a lot simpler on the 
> client.  I kind of wish the actor stuff would be defined in a separate 
> specification.  I don't see us implementing it unless users start asking us 
> to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell  
> wrote:
>> Well, it's already called the "actor claim" so the claimed part is
>> kind of implied. And "claimed actor claim" is a rather awkward.
>> Really, all JWT claims are "claimed something" but they don't include
>> the "claimed" bit in the name. RFC 7519, for example, defines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis  wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encounter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP can do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept, it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No standard
>>> action related to the content of such a claim can be specified in the
>>> spec. If the content of a "claimed actor" is used by the RP, it
>>> should be only used as an hint and thus be subject to other
>>> verifications which are not specified in this specification.
>>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my prior
>>> statements about the actor claim but, for lack of knowing what else
>>> to say, I'm going to kind of repeat what I said about it over in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegation has
>>> happened and identify the entities involved. Access control or other
>>> decisions based on it are at the discretion of the consumer of the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with respect
>>> to whether or not the JWT can be accepted as valid. Some examples are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or something
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify such
>>> processing rules and are solely statements of fact or circumstance.
>>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims are 
>>> good examples of such.
>>> There might be application or policy specific rules applied to the
>>> content of those kinds of claims (e.g. only subjects from a
>>> particular organization are able to access tenant specific data or,
>>> less realistic but still possible, disallow access for tokens issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way for the
>>> issuer of the token to tell the consumer of the token what is going
>>> on. But any action to take (or not) based on that information is at
>>> the discretion of the token consumer. I honestly don't know it could
>>> be anything more. And don't think it should 

[OAUTH-WG] is updated guidance needed for JS/SPA apps?

[Brock Allen]

Much like updated guidance was provided with the "OAuth2 for native apps" RFC, 
should there be one for "browser-based client-side JS apps"? I ask because 
google is actively discouraging the use of implicit flow:

https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290

>From what I can tell, the complaints with implicit are:
* access token in URL
* access token in browser history
* iframe complexity when using prompt=none to "refresh" access tokens

But this requires:
* AS/OP to support PKCE
* AS/OP to support CORS 
* user-agent must support CORS
* AS/OP to maintain short-lived refresh tokens 
* AS/OP must aggressively revoke refresh tokens at user signout (which is not 
something OAuth2 "knows" about)
* if the above point can't work, then client must proactively use revocation 
endpoint if/when user triggers logout

Any use in discussing this?

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

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

[Hannes Tschofenig]

Hi Brock,

there have been several attempts to start writing some guidance but so far we 
haven’t gotten too far.
IMHO it would be great to have a document.

Ciao
Hannes

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org
Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

Much like updated guidance was provided with the "OAuth2 for native apps" RFC, 
should there be one for "browser-based client-side JS apps"? I ask because 
google is actively discouraging the use of implicit flow:

https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290

From what I can tell, the complaints with implicit are:
* access token in URL
* access token in browser history
* iframe complexity when using prompt=none to "refresh" access tokens

But this requires:
* AS/OP to support PKCE
* AS/OP to support CORS
* user-agent must support CORS
* AS/OP to maintain short-lived refresh tokens
* AS/OP must aggressively revoke refresh tokens at user signout (which is not 
something OAuth2 "knows" about)
* if the above point can't work, then client must proactively use revocation 
endpoint if/when user triggers logout

Any use in discussing this?

-Brock

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth