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_92...@yahoo.com<mailto:wmills_92...@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." <jric...@mitre.org<mailto:jric...@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_92...@yahoo.com<mailto:wmills_92...@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
