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

[Eric Rescorla <[e-mail]>]

That would go a long way, I think. Do you think that C's permissions matter
at all? So, say that the resource is accessible to C but not A?

-Ekr




On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <[e-mail]>
wrote:

> Hi Eric,
>
> Apologies for my somewhat slow response. I've honestly been unsure of how
> else to try and address the comment/question. But will continue trying...
>
> My expectation would be that access control decisions would be made based
> on the subject of the token itself or on the current actor. And maybe a
> combination of both in some situations (like, for example, the actor is an
> administrator and the token allows admin level access to the stuff the
> token subject would normally have access to).  However, I don't believe
> that nested prior actors would or should be considered in access control
> decisions. The nesting is more just to express what has happened for
> auditing or tracking or the like. To be honest, the nesting was added in
> the draft largely because the structure naturally and easily allowed for it
> and it seemed like it might be useful information to convey in some cases.
>
> So in that A->B->C case (the claims of such a token would, I think, look
> like the JSON below), B *is not* giving C his authority. B is just noted
> in the token as having been involved previously.  While A is identified as
> the subject of the token and C is the current actor.
>
>     {
>       "aud":"... ,"iss":... , "exp":..., etc. etc. ...
>       "sub":"A",
>       "act":
>       {
>         "sub":"C",
>         "act":
>         {
>           "sub":"B"
>         }
>       }
>     }
>
>
> Would some text explicitly saying that only the token subject (top level
> sub and claims) and the party identified by the outermost "act" claim (the
> current actor) are to be considered in access control decisions address
> your concern?
>
>
> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla <[e-mail]> wrote:
>
>> Hi Brian,
>>
>> To be clear, I'm not opposing Delegation. My concern here is that we have
>> a chain of signed assertions and I'm trying to understand how I as a
>> consumer of those assertions am supposed to evaluate it.
>>
>> I don't think it's sufficient to just say that that the access control
>> rules are local policy, because then the entity generating the signature
>> has no way of knowing how its signature will be used.
>>
>> To go back to the case I gave in my initial e-mail, say we have a chain
>> A->B->C and a resource that A and C could ordinarily not access, but B can.
>> If C has this delegation, can C access the resource? I.e., is B giving C
>> his authority or just passing on A's authority? It seems pretty important
>> for B to know that before he gives the token to C.
>>
>> -Ekr
>>
>>
>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <
>> [e-mail]> wrote:
>>
>>> Delegation has been in the document since its inception and throughout
>>> the three and a half years as a working group document.
>>>
>>> From a process point of view, the document is now in AD Evaluation. I
>>> worked through a number of questions and clarifications with Eric (said
>>> AD), however he raised the particular questions that started this thread on
>>> the WG list. And I responded with an attempt at addressing those questions.
>>> That was about a month ago.
>>>
>>> Eric, was my explanation helpful in clarify anything for you? Is there
>>> some text that you'd like to see added? Something else? I'm unsure how to
>>> proceed but would like to move things forward.
>>>
>>>
>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke <[e-mail]> wrote:
>>>
>>>> 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 <
>>>> [e-mail]> 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 <[e-mail]> On Behalf Of Bill Burke
>>>> > Sent: Thursday, May 17, 2018 2:11 PM
>>>> > To: Brian Campbell <[e-mail]>
>>>> > Cc: oauth <[e-mail]>
>>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang
>>>> e-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 <
>>>> [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
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Bill Burke
>>>> > Red Hat
>>>> >
>>>> > _______________________________________________
>>>> > OAuth mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>>
>>>
>>>
>>> *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.*
>>
>>
>>
>
> *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.*
>