Hunt
Date:12/02/2014 8:25 PM (GMT-05:00)
To: Justin Richer
Cc: oauth@ietf.org
Subject: 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 d
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
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
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
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
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
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
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
+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
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
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
>> Rancho Santa Margarita, CA 92688-3836
>>
>> Phone: (949) 636-8571
>> Email: donald.cof...@reminetworks.com
>> <mailto:donald.cof...@reminetworks.com>
>>
>> From: Justin Richer [mailto:jric...@mit.edu <mailto:jric...@mit.edu>]
>>
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
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
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
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
com>
From: Richer, Justin P. [mailto:jric...@mitre.org]
Sent: Tuesday, December 2, 2014 10:19 AM
To: Donald Coffin
Cc: Justin Richer; Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
No, this isn't an appropriate mapping i
"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
o: Hannes Tschofenig; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: 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
, CA 92688-3836
>
>
>
> Phone: (949) 636-8571
>
> Email: donald.cof...@reminetworks.com
>
>
>
> *From:* Justin Richer [mailto:jric...@mit.edu]
> *Sent:* Tuesday, December 2, 2014 6:06 AM
> *To:* Hannes Tschofenig; oauth@ietf.org
> *Subject:
hone: (949) 636-8571
Email: donald.cof...@reminetworks.com
<mailto:donald.cof...@reminetworks.com>
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Tuesday, December 2, 2014 6:06 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-i
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,
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
>> 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
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
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
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
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
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
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
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
31 matches
Mail list logo
