FWIW, UMA goes ahea= d and standardizes a good deal about the trust establishment between the RS a= nd the AS, and (of course) profiles and wraps the token introspection spec a= s part of the resulting =E2=80=9Cauthorization API=E2=80=9D that the AS pres= ents to the RS. A big part of the motivation for this is to support an n:n r= elationship between AS and RS entities.

EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
=
Many of the proprietary introspection protocols in u= se return scope, role or other meta data for the RS to make its access polic= y decision on.
One of the reasons for using opaque tokens rat= her than JWT is to prevent leakage of that info.

Making authentication to the introspection en= dpoint 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=E2=80=99t addressed in this spec i= s what happens if there are multiple AS for the RS and how it would decide w= hat introspection endpoint to use.
Perhaps that needs t= o 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= . <jricher@mitre.org&= gt; wrote:

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

-- Justin

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

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

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

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

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 introspe= ction endpoint returns the symmetric key? Data about the user? Where does this blur the line between this and "act on behalf o= f"?

On Tuesday, December 2, 2014 11:05 AM, "Richer, J= ustin P." <jri= cher@mitre.org> wrote:

The ca= ll to introspection has a TLS requirement, but the call to the RS wouldn't n= ecessarily 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 a= ssociated with it and the request. What I'm saying is that you introspect th= e identifier and get back something that lets you, the RS, check the signatu= re.

= -- Justin

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

"However, I t= hink 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) w= ould then also have a TLS or transport security requirement unless there is t= oken introspection client auth in play I think. Otherwise I can as an a= ttacker 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 l= ist
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth

____________________________= ___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth

Eve Maler = = ; http://www.xmlgrrl.com/blog
+1 425 345 6756 &nbs= p; &nb= sp; http://www.tw= itter.com/xmlgrrl