+1 for "Making authentication to the introspection endpoint a MUST if
additional attributes are present is OK"
On Tuesday, December 2, 2014 12:15 PM, John Bradley <[email protected]>
wrote:
Many of the proprietary introspection protocols in use return scope, role or
other meta data for the RS to make its access policy decision on.One of the
reasons for using opaque tokens rather than JWT is to prevent leakage of that
info.
Making authentication to the introspection endpoint a MUST if additional
attributes are present is OK, I might even be inclined to say that
authentication of some sort is always required, but that might be going a bit
far for some use cases.
We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. It
would be nice if we could standardize it. Precluding other attributes would
not be helpful for adoption.
One issue that we haven’t addressed in this spec is what happens if there are
multiple AS for the RS and how it would decide what introspection endpoint to
use.Perhaps that needs to be a extension, leaving this for the simple case.
However having more than on e AS per RS is not as unusual as it once was in
larger environments.
John B.
On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <[email protected]> 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 <[email protected]> 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." <[email protected]>
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 <[email protected]> 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." <[email protected]>
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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
