On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <jricher@mitre.org> = wrote:

Agreed, which is why we've got space for the "sub" and "user_id" fields = but not anything else about the user, and we've got a privacy = considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it.

-- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

If introspection = returns any other user data beyond what is strictly required to validate = the token based solely on possession of the public part it would be a mistake.

On = Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> = wrote:

That's all fine -- it's all going = over TLS anyway (RS->AS) just like the original token fetch by the = client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) = with a good PoP token.

Can you explain how this is related to "act on behalf = of"? I don't see any connection.

-- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what = if the introspection endpoint returns the symmetric key? Data = about the user? Where does this blur the line between this and "act on = behalf of"?

On Tuesday, December 2, 2014 11:05 = AM, "Richer, Justin P." <jricher@mitre.org> wrote:

The = call to introspection has a TLS requirement, but the call to the RS = wouldn't necessarily have that requirement. The signature and the token = identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature = that's associated with it and the request. What I'm saying is that you = introspect the identifier and get back something that lets you, the RS, = check the signature.

-- Justin

On = Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear = how PoP tokens would work. ..."

I don't know if that's true. POP tokens (as yet to be fully = defined) would then also have a TLS or transport security requirement = unless there is token introspection client auth in play I think. = Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we = want.

-bill

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth