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

This text is fine. I have issued IETF-LC. On Mon, Jun 4, 2018 at 1:45 PM, Brian Campbell wrote: > Thanks Eric, I've added text in the just submitted -14 saying that only > the two ends of the chain are to be considered in access control policy > decisions. > > diff: > https://www.ietf.org/rfcdif

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

Thanks Eric, I've added text in the just submitted -14 saying that only the two ends of the chain are to be considered in access control policy decisions. diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-14 htmlized: https://tools.ietf.org/html/draft-ietf-oauth-token-exchan

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

OK, well, it seems like it ought to say that that generator of the token can expect that the RP will apply an access control policy that s the union of the capabilities of the two ends of the chain -- and that while it might be less it won't be more. -Ekr On Fri, Jun 1, 2018 at 3:15 PM, Brian Ca

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

I suspect that the vast majority of time C's permissions won't matter at all. But I do think there are legitimate cases where they might be considered in the policy decision. One general example I can think of is a customer service rep or administrator taking override type corrective action on an e

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

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 wrote: > Hi Eric, > > Apologies for my somewhat slow response. I've honestly been unsure of how > e

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

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 ma

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

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 o

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

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

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

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

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

ave 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 opin

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

+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

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

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

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 claime

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

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 suc

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

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 col

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

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