Re: [OAUTH-WG] Resource Service metadata

I’m assuming that in many cases, the “aud” concept is opaque or even non-existent to clients. It would be hard for them to translate one to the other. However, it may be that in some resource discovery cases, they are passing a URI (an RSID?) to a discovery service and the discovery translates

Re: [OAUTH-WG] Resource Service metadata

On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote: George Very good question... I considered that the RS metadata discovery could be fake. Same way that the 'iss' claim must "match" the url used to retrieve the metadata would apply to the 'rsid' claim -- I think that should suffice to ensuring the

Re: [OAUTH-WG] Resource Service metadata

agreed, I'm not suggesting that the client-to-evil-RS problem is addressed, I was objecting to the statement that Phil made about static configurations not being a problem; I don't think agreement was reached on a client-to-evil-AS solution either Hans. On 3/17/16 5:31 PM, George Fletcher wro

Re: [OAUTH-WG] Resource Service metadata

I agree with Phil that the client can’t trust any abstract identifier that it might get from a bad RS unless it is were a URI that the client or AS could deference to get a list of the concrete URI for the RS. That seems like a lot of work that clients are unlikely to do. A AS might do it if it

Re: [OAUTH-WG] Resource Service metadata

But it’s less likely (or less easy?) to have a malicious combination of endpoints in a static configuration. What this all boils down to is managing a set of endpoints as a “thing” that represents an AS (and some would argue associated RS). You can create that set manually or dynamically and fal

Re: [OAUTH-WG] Resource Service metadata

Inline... On 3/16/16 2:16 PM, Phil Hunt wrote: Phil @independentid www.independentid.com phil.h...@oracle.com On Mar 16, 2016, at 10:59 AM, George Fletcher > wrote: On 3/16/16 12:20 PM, Phil Hunt (ID

Re: [OAUTH-WG] Resource Service metadata

Phil @independentid www.independentid.com phil.h...@oracle.com > On Mar 16, 2016, at 10:59 AM, George Fletcher wrote: > > > > On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote: >> George >> >> Very good question... >> >> I consider

Re: [OAUTH-WG] Resource Service metadata

I keep saying that the mixup mitigation draft doesn't require discovery. The AS meta-data draft started before the mixup mitigation work and is not related, other than that they both use the concept of issuer, as do you. The mixup doesn’t require discovery but it arguably makes it easier. Jo

Re: [OAUTH-WG] Resource Service metadata

I'm sorry to keep pushing on this but the attack is not opened up by discovery, having two fixed ASes is already a threat: multiple ASes in general leaves the client exposed. Discovery just increases the attack surface. Hans. On 3/17/16 4:16 PM, Phil Hunt wrote: George, For the attacks we l

Re: [OAUTH-WG] Resource Service metadata

George Very good question... I considered that the RS metadata discovery could be fake. So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid. We are of course assuming that a hacker needs to use th

Re: [OAUTH-WG] Resource Service metadata

Isn't the solution to that attack defined? I was not including that attack in the thinking around audience restricted tokens and AS / RS endpoint "discovery". I think that regardless of this current discussion the requirement for the AS to return issuer and client_id needs to stay as does the b

Re: [OAUTH-WG] Resource Service metadata

The aud of the access token is completely opaque to the client in all cases, with the possible exception of someone who is using scopes to represent resources and the client has some mapping of scopes granted to RS endpoints. I am just trying to find a less confusing way to do that without the

Re: [OAUTH-WG] Resource Service metadata

George, For the attacks we looked at in Darmstadt, we discussed that in order for the attack to succeed (at least as envisioned), the attacker needs to have the client invoke the real authorize endpoint in order for the user to be successful in issuing the grant. Assuming that it is the case,

Re: [OAUTH-WG] Resource Service metadata

Static deployments are a problem for mix-up. Agreed. I’m objecting to the notion that we don’t have to worry about discovery threats and that we need to do mix-up first. Rushing ahead with partial discovery so we can address mix-up seems like a *huge* mistake. Mix-up depends on a bad insider t

Re: [OAUTH-WG] Resource Service metadata

a good AS (at first) may become compromised and attack another AS; whilst I agree it is less likely and less easy in static configs (hence my point about the dynamic scenario) the root cause is not related to configuration: it is a runtime attack (well at least one of the permutations is) on pe

Re: [OAUTH-WG] Resource Service metadata

George, Thanks. It would be good to get a draft that sketches out the overall picture of this for BA — even if in very rough form given the deadline is monday. Or, maybe just a PPT walkthru. Interested to see what comes out. Phil @independentid www.independentid.com

[OAUTH-WG] Resource Service metadata

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata. For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving t

Re: [OAUTH-WG] Resource Service metadata

On 3/16/16 6:37 PM, John Bradley wrote: I agree with Phil that the client can’t trust any abstract identifier that it might get from a bad RS unless it is were a URI that the client or AS could deference to get a list of the concrete URI for the RS. I guess I'm confused on this front as we are