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

[George Fletcher <[e-mail]>]

I'm fine with it being optional but I don't think it should be removed. 
I have a use case where the actor_token is being used. In my use case 
the "actor" represents a device making a token exchange between two 
applications running on the device. It allows the AS to enforce a 
binding such that only apps on the same device can exchange tokens.

Full details can be found on the OpenID Connect working group mailing list:
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180430/006733.html

Thanks,
George

On 5/17/18 8:10 AM, 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
> <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem
>>>> generally OK. I do still have one remaining concern, which is about
>>>> the actor claim. Specifically, what is the RP supposed to do when they
>>>> encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that everyone in
>>>>     the chain signed off on the next person in the chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presenting the token
>>>>     is the identity at the top of the chain? Say I have the
>>>>     delegation A -> B -> C, and there is some resource which
>>>>     B can access but A and C cannot, should I give access?
>>>>
>>>> I think the first question definitely needs an answer. The second
>>>> question I guess we could make not answer, but it's pretty hard
>>>> to know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>>> material for the sole use of the intended recipient(s). Any review, use,
>>> distribution or disclosure by others is strictly prohibited..  If you have
>>> received this communication in error, please notify the sender immediately
>>> by e-mail and delete the message and any file attachments from your
>>> computer. Thank you.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited..  If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>