‎Panca.blogspot.com

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: [email protected]
Terkirim: Rabu, 3 Desember 2014 03.00
Ke: [email protected]
Balas Ke: [email protected]
Perihal: OAuth Digest, Vol 74, Issue 24


Send OAuth mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: Review of draft-ietf-oauth-introspection-01
      (Richer, Justin P.)


----------------------------------------------------------------------

Message: 1
Date: Tue, 2 Dec 2014 19:56:35 +0000
From: "Richer, Justin P." <[email protected]>
To: Bill Mills <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"

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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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








-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/6392a329/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 74, Issue 24
*************************************
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to