Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Ah, I think I got my threads crossed. Then yes, I agree with you, and I'm going to be making authorization a MUST instead of a SHOULD. Would love to hear feedback from other implementers on this point.  -- Justin / Sent from my phone / Original message From: Phil Hunt Dat

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

I was asking in the context of the thread where the comment was made that you only need to authenticate if more information is provided. This didn’t make sense to me. Because you would never make the call to re-confirm (pointless). Even a caller re-confirming is actually checking for more infor

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Nothing says you need to pack the same information inside the JWT that you return from introspection. In our specific case, we don't put scopes or client IDs inside the JWT, just basic signature/identifier type stuff, so you need to call introspection to get back this other information. But the

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

I am confused. Why would you call the introspection endpoint if you were not expecting new information to be disclosed? Phil > On Dec 2, 2014, at 14:26, Richer, Justin P. wrote: > > I agree that there's some use in this (and in fact I've deployed a version > that uses a signed JWT to indicate

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

I agree that there's some use in this (and in fact I've deployed a version that uses a signed JWT to indicate its authorization server), but it should remain outside the scope of this spec. It's a service discovery problem, it's orthogonal. -- Justin On Dec 2, 2014, at 5:13 PM, John Bradley

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Yes, but unless there is something new the introspection endpoint in UMA is tied to the resource. In some cases having the token indicate the introspection endpoint may be useful. John B. Sent from my iPhone > On Dec 2, 2014, at 10:02 PM, Eve Maler wrote: > > FWIW, UMA goes ahead and

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

FWIW, UMA goes ahead and standardizes a good deal about the trust establishment between the RS and the AS, and (of course) profiles and wraps the token introspection spec as part of the resulting “authorization API” that the AS presents to the RS. A big part of the motivation for this is to supp

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

OK, I'm taking a note to make it a MUST in general in the next draft, and we can dial back from there if there are honest, specific use cases where it doesn't make sense. Thanks. -- Justin On Dec 2, 2014, at 3:35 PM, Bill Mills mailto:wmills_92...@yahoo.com>> wrote: +1 for "Making authentic

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

+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 wrote: Many of the proprietary introspection protocols in use return scope, role or other meta data for the RS to make

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

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

[OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 24

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

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

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 P

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

+1 > On Dec 2, 2014, at 3:19 PM, Richer, Justin P. wrote: > > No, this isn't an appropriate mapping in this case, especially if the > introspection endpoint is itself OAuth protected. You need to be able to > differentiate between the token being asked about and the token authorizing > the que

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

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." wrote: That's all fine -- it's all going over TLS anyw

[OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 21

llowed and left at the discretion of the implementation. As an implementer, unless I'm told that I could use access_token in the request body, I would assume only the Authorization header is accepted. Noted, I'll change these to 401. Thanks very much! -- Justin -- nex

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

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

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

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." wrote: The call

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

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 i

Re: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01

Thomas, thanks for the review. Responses inline. On Dec 2, 2014, at 11:08 AM, Thomas Broyer mailto:t.bro...@gmail.com>> wrote: Hi, Here are some notes about draft-ietf-oauth-introspection-01. Background: I have implemented and deployed -00 (actually that was some version of the individual draf

Re: [OAUTH-WG] draft-ietf-oauth-introspection

1. Answer is still unclear, Is the metadata (introspection response) being returned from the authorization endpoint or from the token or a combination of both ? The answer needs to go in the spec 2. Spec needs to contain this information about stateless tokens 3. For interoper

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Justin, Thanks for the clarification. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

"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 ta

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

No, this isn't an appropriate mapping in this case, especially if the introspection endpoint is itself OAuth protected. You need to be able to differentiate between the token being asked about and the token authorizing the question. These error codes apply to the latter and should not be conflat

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

So what? The request is OK (no missing parameter, etc.) so a 400 is not appropriate (it could still be used, but you couldn't tell what went wrong without *also* having some well-defined error response document format; and an "invalid_token" error code wouldn't work if you're also using token auth

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Justin, I believe you will find the answer to which HTTP Status code the AS should return if the token is INACTIVE in Section 3.1 Error Codes of "The OAuth 2.0 Framework: Bearer Token Usage" [RFC6750] which states: 3.1. Error Codes When a request fails, the resource server responds usi

[OAUTH-WG] Notes on draft-ietf-oauth-introspection-01

Hi, Here are some notes about draft-ietf-oauth-introspection-01. Background: I have implemented and deployed -00 (actually that was some version of the individual draft, before it got adopted by the WG), currently with only a couple "clients" (out of 20 or so OAuth 2.0 clients currently, only a co

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

If you're not torturing the metaphors, you're not really trying. :) And, in case it wasn't clear before, I am very open to better text in Appendix C if anyone wants to suggest something. -- Justin On Dec 2, 2014, at 10:44 AM, Sergey Beryozkin wrote: > Hi Justin, > On 02/12/14 15:36, Richer,

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Justin, On 02/12/14 15:36, Richer, Justin P. wrote: However, I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response, which is effectively the public portion of the PoP token. Just like a bearer token, this value is pa

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

>> However, I think it's very clear how PoP tokens would work. You send the >> value returned as the "access_token" in the token endpoint response, >> which is effectively the public portion of the PoP token. Just like a >> bearer token, this value is passed as-is from the client to the RS and >> w

[OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-21.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Justin Please see a comment below On 02/12/14 14:05, Justin Richer wrote: Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token int

[OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 12

op tokens Ultimately, we are really only talking about a document management issue here. I assume that we want to have support for introspection with PoP tokens as well and we might just end up dumping the text into the HTTP signing draft (as an extension to the token introspection doc). Ciao Han

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already ha

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Sergey, comments below. On 12/02/2014 01:39 PM, Sergey Beryozkin wrote: > Hi Hannes > > Thanks for the clarifications, comments below... > On 02/12/14 12:02, Hannes Tschofenig wrote: >> Hi Sergey, >> >> On 12/02/2014 12:30 PM, Sergey Beryozkin wrote: * Scope I think the d

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Hannes Thanks for the clarifications, comments below... On 02/12/14 12:02, Hannes Tschofenig wrote: Hi Sergey, On 12/02/2014 12:30 PM, Sergey Beryozkin wrote: * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue w

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Sergey, On 12/02/2014 12:30 PM, Sergey Beryozkin wrote: >> >> * Scope >> >> I think the document needs to be very clear that is only applicable to >> bearer tokens (and not to PoP tokens). This issue was raised at the last >> IETF meeting as well. >> > Interesting, I was reading the doc yesterd

[OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 10

a user consent and you're covered legally and then the drive is to make that consent as minimally invasive (read effective) as possible. -- next part -- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/323a1

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Hannes On 02/12/14 11:23, Hannes Tschofenig wrote: Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of t

[OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource