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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]> On Behalf Of Bill Burke >>>> > Sent: Thursday, May 17, 2018 2:11 PM >>>> > To: Brian Campbell <[email protected]> >>>> > Cc: oauth <[email protected]> >>>> > 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 < >>>> [email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 >>>> >>>> [email protected] >>>> >>>> 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 >>>> >>> [email protected] >>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> OAuth mailing list >>>> >>> [email protected] >>>> >>> 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 >>>> >> [email protected] >>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Bill Burke >>>> > Red Hat >>>> > >>>> > _______________________________________________ >>>> > OAuth mailing list >>>> > [email protected] >>>> > 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.* >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
