Re: [OAUTH-WG] OAuth Digest, Vol 74, Issue 31

[Brian Thaga <[e-mail]>]

On Wed, Dec 3, 2014 at 3:37 AM, <[e-mail]> wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> 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
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> 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 (Justin Richer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 02 Dec 2014 20:36:59 -0500
> From: Justin Richer <[e-mail]>
> To: Phil Hunt <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <[e-mail]>
> Date:12/02/2014  8:25 PM  (GMT-05:00)
> To: Justin Richer <[e-mail]>
> Cc: [e-mail]
> 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 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 information - to see if the assertion has been revoked.
>
> Phil
>
> @independentid
> www.independentid.com
> [e-mail]
>
> On Dec 2, 2014, at 5:04 PM, Justin Richer <[e-mail]> wrote:
>
> 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
> information inside the JWT includes an "iss" claim which the client can use
> to figure out *which* introspection endpoint to call.
>
> This is just one of many different ways you could handle multiple AS at a
> single resource, and so it's definitely orthogonal to the basic
> introspection concept.
>
>  -- Justin
>
> On 12/2/2014 6:38 PM, Phil Hunt wrote:
> 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. <[e-mail]> 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 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 <[e-mail]> wrote:
>
> 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 <[e-mail]> wrote:
>
> 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
> support an n:n relationship between AS and RS entities.
>
> EVe
>
> On 2 Dec 2014, at 12:14 PM, John Bradley <[e-mail]> 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. <[e-mail]> 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 <[e-mail]> 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." <
> [e-mail]> 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 <[e-mail]> 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." <
> [e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Eve Maler http://www.xmlgrrl.com/blog
> [phone] http://www.twitter.com/xmlgrrl
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/97e34bdb/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 74, Issue 31
> *************************************
>