Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550F51A7004 for ; Mon, 1 Dec 2014 16:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4hgmra4vbtC for ; Mon, 1 Dec 2014 16:42:06 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74ED1A701B for ; Mon, 1 Dec 2014 16:42:05 -0800 (PST) X-AuditID: 1209190d-f793c6d000001ec0-27-547d0adc7e9d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.73.07872.CDA0D745; Mon, 1 Dec 2014 19:42:04 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sB20g3rc028263; Mon, 1 Dec 2014 19:42:04 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB20fxXm008923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Dec 2014 19:42:02 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Justin Richer In-Reply-To: Date: Mon, 1 Dec 2014 19:41:58 -0500 Message-Id: <4B1239F5-5DD3-4F1B-8691-75E8B07F3891@mit.edu> References: <375CE45E-8896-4BD1-B398-ECE53A464BF7@mit.edu> To: Anthony Nadalin X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDKsWRmVeSWpSXmKPExsUixCmqrXuHqzbE4P4iIYuTb1+xWWyau43R gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGVsv5BTcGcOU8X8rZ3MDYzbvzJ2MXJySAiY SBxbdZAJwhaTuHBvPVsXIxeHkMBsJoklG9exgySEBDYwSnzo8YVI3GCSeDf/FVgVs8AkRon+ i7OZQap4BQwkluzaBGYLC5hJrFvawgZiswmoSkxf0wK2glMgUeLhhhlgNSwCKhLzp+wHO4MZ qObLgvdMEHOsJO4seQJ1xhNGibONt8GKRAS0JU68X8kMcau8xIcPx9knMArMQnbILCSHzAIb nCSx/+JaJghbW2LZwtdQcQOJp52vWDHF9SXevJsDVS8vsf3tHKi4pcTimTdYIGxbiVt9C6Bq 7CQeTVvEuoCRexWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZwxEny7mB8d1Dp EKMAB6MSD++J8zUhQqyJZcWVuYcYJTmYlER5F34ECvEl5adUZiQWZ8QXleakFh9iVAHa9WjD 6guMUix5+XmpSiK8j0FaeVMSK6tSi/JhyqQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ 8O7krA0REixKTU+tSMvMKUFIM3FwHmKU4OABGv4NpIa3uCAxtzgzHSJ/ilFRSpxXD5jqhARA EhmleXC9sET5ilEc6C1h3n0g7TzAJAvX/QpoMBPQYIbmSpDBJYkIKakGRt/s3XcEywXTXrwy Ov4370/Uc8O3K/mK33oGB0Wsr1Jn+sNaJNRwWjihVuLtiX27jxk62K7YtfX4sg3zOVfLSJ6Q efuEfZmm0KVpaXl2fKnbnshdkP8415Rrl8KXxqtnN1m0p+hurnuZcnVC6Y/vx47u4v1wMLv9 pvND18yFyoLn6k629VtpTlNiKc5INNRiLipOBAD6ZCCEbwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6bBFvbtVneUV6ES8Mz1Z3TAlb4w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 00:42:10 -0000 --Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526 Content-Type: multipart/alternative; boundary="Apple-Mail=_DBB884AC-34D1-4CEA-ADC1-B3CB701B0BF2" --Apple-Mail=_DBB884AC-34D1-4CEA-ADC1-B3CB701B0BF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > 1. Is the metadata (introspection response) being returned from = the authorization endpoint or from the token or a combination of both ? As I said below, ultimately it=92s about the token and what it = represents. If the token was issued through use of the authorization = endpoint, then it=92s likely that there=92s some context from that = authorization endpoint tied to the token that can be returned. > 2. =93context=94 there may be no context other than the token, = are you expecting the authorization endpoint to always keep a context of = how/why the token was issued ? If you=92re asking if stateless tokens can be supported with this, then = yes, that=92s fine. If the token=92s completely on its own (like a = structured token generated as an assertion and used as an OAuth 2.0 = access token) and a server=92s able to unpack that for a client without = access to other pieces of context, then that=92s what it returns. But in = that case, if you=92re issuing stateless tokens, with self-contained = metadata and expirations and no other context to be conveyed beyond = what=92s already inside the token, then you=92d probably just tell your = protected resources how to parse and handle them directly.=20 > 3. The specification should clearly state which type of tokens = are supported and what profiles/bindings are supported, like JWT Bearer, = etc. That=92s opaque to the protected resource for purposes of this protocol, = just like a token is opaque to a client for purposes of 6749/6750 OAuth. = The introspection protocol supports whatever tokens are supported by the = AS, so we don=92t need to list token types, but maybe we can be clearer = about the opaqueness of the token value in this process. Since these are = OAuth tokens and not assertions, no bindings or profiles are needed = beyond this. It=92s a simple query-response and it=92s up to the server = to know how to fulfill this contract.=20 > 4. If I have an SAML Bearer assertion, and the SAML assertion is = encrypted and have no way to know this, it can potentially fail if it = can=92t be decrypted but as far as I can tell I=92m not sending an = encrypted token since this is just a SAML assertion, not sure how one = really determines what is wrong If the AS can=92t decrypt the token then it can=92t introspect it. So it = doesn=92t in this case. And if you=92re issuing encrypted OAuth tokens = with no means to decrypt them back at the AS, then you probably wouldn=92t= offer an introspection service to begin with. This is covered in the = security considerations section already. > 5. Should be spelled out what =93active=94 is supposed to mean = so folks get the same results on different endpoints As I said below, it means to answer =93is this token still good or not?=94= for a protected resource that can=92t answer that on its own, and I = believe the current definition reflects that. Please submit text if the = existing definition is insufficient or unclear to you. =97 Justin > =20 > =20 > From: Justin Richer [mailto:jricher@mit.edu]=20 > Sent: Sunday, November 30, 2014 6:57 PM > To: Anthony Nadalin > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection > =20 > Tony, thanks for the comments. Your timing is great, as I was just = today sitting down to polish the introspection draft into a proper WG = document ready for the last-call tomorrow. I=92ve just posted the = updated draft, and I think that you=92ll find it addresses your = concerns. More direct answers inline: > =20 > =20 > On Nov 30, 2014, at 1:01 PM, Anthony Nadalin = wrote: >=20 >=20 > Comments > =20 > Intro > =93about the authentication conext=94, not sure what this is since = there is no authentication context in Oauth > =20 > There are several authentication contexts in OAuth: the resource owner = at the authorization endpoint, the client at the token endpoint, etc. = Regardless, this is meant to be the context of the authorization = decision, text now reads: "context in which the token was issued" >=20 >=20 > Use of Oauth2, mixed with use of Oauth, pick one > =20 > All usage changed to =93OAuth 2.0=94 throughout the document, let me = know if I missed any. >=20 >=20 > =93allows holder of a token to query=94 so anything/anyone that has a = token can use this endpoint? > =20 > Now reads authorized holder of the token and has stronger language and = recommendations about requiring authorization on the endpoint to prevent = public token fishing. This was already addressed in the security = considerations section, but that has been propagated throughout the = specification now.=20 >=20 >=20 > =20 > Introspection Endpoint > Use of Oauth2, mixed with use of Oauth, pick one > =20 > =20 > See above. >=20 >=20 >=20 > Introspection Request > The endpoint SHOULD also require some form of authentication=94, what = about some form of authorization ? Why do we have to have another = endpoint that we have to manage and then have a management API draft?] > =20 > This is now clearer that it needs to be an authorized protected = resource. This authorization may be carried through a credential = mechanism as defined in OAuth 2.0, through an access token, or through = some other mechanism.=20 >=20 >=20 > =20 > Token =96 is this any type of token ? how does the endpoint know that = it can deal with this token type? > =20 > Clarified that it=92s either the access_token from the token endpoint = or the refresh_token from the token endpoint. You can use this with = other token types, but that=92s not defined in this spec which concerns = itself with RFC6749/RFC6750.=20 >=20 >=20 > So endpoint has to try to lookup token to determine if it can maybe = find out something about the token? > =20 > That=92s the idea, the protected resource is asking an authoritative = source (the authorization server) about a given token. I had always = thought it was obvious that the authorization server would have to be = able to know something about the token in order to provide an = introspection service, but since that seems to have been unclear to some = I=92ve made it explicit in the security considerations section.=20 >=20 >=20 > Can the one use the authorization code or does one have to get a token = first? > =20 > No, this is for tokens only. I don=92t see the point of introspecting = an authorization code =97 those aren=92t sent to protected resources, = they=92re sent to clients, which would in turn just hand it to the token = endpoint to get a token. There=92s nothing else to find out about it. >=20 >=20 > Can I send a encrypted token and expect a proper response ? > =20 > If the server can decrypt or otherwise understand the token, yes. I=92ve= pointed out this requirement in the security considerations section.=20 >=20 >=20 > What about a Proof of Possession Token? > =20 > Yes, I think this fits great with PoP tokens, but those aren=92t = defined well enough yet to say anything concrete. As the PoP work = progresses, we can have an extension document to determine what needs to = be done there. Note that we=92ll have to do the same thing with the = Revocation RFC. >=20 >=20 > Introspection Response > What is =93active=94 mean ? Is this up to the server to determine ? > =20 > It means the token is live, hasn=92t been revoked, was actually issued = by this server, isn=92t expired, and the protected resource that=92s = asking has the right to know all that information. This is all up to the = server to determine. If the server can=92t determine that information = for its own tokens, it probably shouldn=92t be offering this service. >=20 >=20 > =93scope OPTIONAL=94, is this the scope in the token or is this the = scope that the introspection endpoint sources may have ? It=92s unclear = if all these return values are from the token or from the introspection = endpoint sources ? > =20 > These are the scopes of the token. All return values are, as stated, = metadata about the token itself that is being queried against. >=20 >=20 > What error codes/conditions are there? Just the 400 (bad request)? > =20 > The errors are more clearly spelled out. Most of it involves bad = client authentication (when client credentials are used), bad = authorization (when access tokens are used to access the introspection = endpoint itself), or the like. If the token being introspected isn=92t = good, that=92s still a 200 response =97 the request is fine, but the = token being introspected isn=92t active, which is what=92s returned. = This isn=92t an error, it=92s a valid answer to the question of =93what = is this token?=94 that=92s being asked every time introspection is = called. >=20 >=20 > Can the endpoint return a encrypted response ? > =20 > That=92s outside the scope of this document. It returns JSON like the = rest of OAuth. >=20 >=20 > What about PII such as user_id, aud ? > =20 > This is now covered in the Privacy Considerations section, which = wasn=92t A Thing when this draft was first written. > =20 > =97 Justin >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail=_DBB884AC-34D1-4CEA-ADC1-B3CB701B0BF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

1.       Is the = metadata (introspection response) being returned from the authorization = endpoint or from the token or a combination of both = ?


As I said = below, ultimately it=92s about the token and what it represents. If the = token was issued through use of the authorization endpoint, then it=92s = likely that there=92s some context from that authorization endpoint tied = to the token that can be returned.

2.       =93contex= t=94 there may be no context other than the token, are you expecting the = authorization endpoint to always keep a context of how/why the token was = issued ?


If = you=92re asking if stateless tokens can be supported with this, then = yes, that=92s fine. If the token=92s completely on its own (like a = structured token generated as an assertion and used as an OAuth 2.0 = access token) and a server=92s able to unpack that for a client without = access to other pieces of context, then that=92s what it returns. But in = that case, if you=92re issuing stateless tokens, with self-contained = metadata and expirations and no other context to be conveyed beyond = what=92s already inside the token, then you=92d probably just tell your = protected resources how to parse and handle them = directly. 

3.       The = specification should clearly state which type of tokens are supported = and what profiles/bindings are supported, like JWT Bearer, etc.


That=92s opaque = to the protected resource for purposes of this protocol, just like a = token is opaque to a client for purposes of 6749/6750 OAuth. The = introspection protocol supports whatever tokens are supported by the AS, = so we don=92t need to list token types, but maybe we can be clearer = about the opaqueness of the token value in this process. Since these are = OAuth tokens and not assertions, no bindings or profiles are needed = beyond this. It=92s a simple query-response and it=92s up to the server = to know how to fulfill this contract. 

4.       If I = have an SAML Bearer assertion, and the SAML assertion is encrypted and = have no way to know this, it can potentially fail if it can=92t be = decrypted but as far as I can tell I=92m not sending an encrypted token since this is just a SAML assertion, not sure how one really = determines what is = wrong


If the AS = can=92t decrypt the token then it can=92t introspect it. So it doesn=92t = in this case. And if you=92re issuing encrypted OAuth tokens with no = means to decrypt them back at the AS, then you probably wouldn=92t offer = an introspection service to begin with. This is covered in the security = considerations section already.

5.       Should = be spelled out what =93active=94 is supposed to mean so folks get the = same results on different = endpoints


As I = said below, it means to answer =93is this token still good or not?=94 = for a protected resource that can=92t answer that on its own, and I = believe the current definition reflects that. Please submit text if the = existing definition is insufficient or unclear to = you.

 =97 Justin

 

 

From: Justin Richer [mailto:jricher@mit.edu]
Sent: Sunday, November 30, 2014 6:57 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-ietf-oauth-introspection

 

Tony, thanks for the comments. Your timing is great, = as I was just today sitting down to polish the introspection draft into = a proper WG document ready for the last-call tomorrow. I=92ve just = posted the updated draft, and I think that you=92ll find it addresses your concerns. More direct answers inline:

 

 

On Nov 30, 2014, at 1:01 PM, Anthony Nadalin = <tonynad@microsoft.com>= wrote:



Comments

 

Intro

=93about = the authentication conext=94, not sure what this is since there is no = authentication context in Oauth

 

There are several authentication contexts in OAuth: = the resource owner at the authorization endpoint, the client at the = token endpoint, etc. Regardless, this is meant to be the context of the authorization decision, text now reads: "context = in which the token was issued"



Use of Oauth2, mixed with use of Oauth, pick = one

 

All usage changed to =93OAuth 2.0=94 throughout the = document, let me know if I missed any.



=93allows holder of a token to query=94 so = anything/anyone that has a token can use this endpoint?

 

Now reads authorized holder of the token and has = stronger language and recommendations about requiring authorization on = the endpoint to prevent public token fishing. This was already addressed in the security considerations section, but that = has been propagated throughout the specification = now. 



 

Introspection Endpoint

Use of Oauth2, mixed with use of Oauth, pick = one

 

 

See above.




Introspection Request

The endpoint SHOULD also require some form of = authentication=94, what about some form of authorization ? Why do we = have to have another endpoint that we have to manage and then have a = management API draft?]

 

This is now clearer that it needs to be an authorized = protected resource. This authorization may be carried through a = credential mechanism as defined in OAuth 2.0, through an access token, or through some other = mechanism. 



 

Token =96 is this any type of token ? how does the = endpoint know that it can deal with this token type?

 

Clarified that it=92s either the access_token from = the token endpoint or the refresh_token from the token endpoint. You can = use this with other token types, but that=92s not defined in this spec which concerns itself with = RFC6749/RFC6750. 



So endpoint has to try to lookup token =  to determine if it can maybe find out something about the = token?

 

That=92s the idea, the protected resource is asking = an authoritative source (the authorization server) about a given token. = I had always thought it was obvious that the authorization server would have to be able to know something about the token in order = to provide an introspection service, but since that seems to have been = unclear to some I=92ve made it explicit in the security considerations = section. 



Can the one use the authorization code or = does one have to get a token first?

 

No, this is for tokens only. I don=92t see the point = of introspecting an authorization code =97 those aren=92t sent to = protected resources, they=92re sent to clients, which would in turn just hand it to the token endpoint to get a token. There=92s = nothing else to find out about it.



 Can I send a encrypted token and = expect a proper response ?

 

If the server can decrypt or otherwise understand the = token, yes. I=92ve pointed out this requirement in the security = considerations section. 



What about a Proof of Possession Token? =

 

Yes, I think this fits great with PoP tokens, but = those aren=92t defined well enough yet to say anything concrete. As the = PoP work progresses, we can have an extension document to determine what needs to be done there. Note that we=92ll have to do = the same thing with the Revocation RFC.



 Introspection = Response

What is =93active=94 mean = ? Is this up to the server to determine ?

 

It means the token is live, hasn=92t been revoked, = was actually issued by this server, isn=92t expired, and the protected = resource that=92s asking has the right to know all that information. This is all up to the server to determine. If the server = can=92t determine that information for its own tokens, it probably = shouldn=92t be offering this service.



=93scope OPTIONAL=94, is this the scope in = the token or is this the scope that the introspection endpoint sources = may have ? It=92s unclear if all these return values are from the token = or from the introspection endpoint sources ?

 

These are the scopes of the token. All return values = are, as stated, metadata about the token itself that is being queried = against.



What error codes/conditions are there? Just = the 400  (bad request)?

 

The errors are more clearly spelled out. Most of it = involves bad client authentication (when client credentials are used), = bad authorization (when access tokens are used to access the introspection endpoint itself), or the like. If the token = being introspected isn=92t good, that=92s still a 200 response =97 the = request is fine, but the token being introspected isn=92t active, which = is what=92s returned. This isn=92t an error, it=92s a valid answer to the question of =93what is this token?=94 that=92s being = asked every time introspection is called.



Can the endpoint return a encrypted response = ?

 

That=92s outside the scope of this document. It = returns JSON like the rest of OAuth.



What about PII such as user_id, aud = ?

 

This is now covered in the Privacy Considerations = section, which wasn=92t A Thing when this draft was first = written.

 

 =97 Justin



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

 


= --Apple-Mail=_DBB884AC-34D1-4CEA-ADC1-B3CB701B0BF2-- --Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUfQrWAAoJEDPAngkbd+w99AQH/3HFF0g6CisDJu+gLE8jFb8c weVun5j9yygptOOVsvFp1ChHsPn8OiEi5scitCz7hSmELXNkrfAGlC2u1Vq3tpRg W9aA0q8J8xcvkowgyXlkvBx+7NP/UCotNTbdxfN4mF7BGvw85NjP9RfvY3/ZAbkG 8fz3Whx22UNhQhKeCa90iiabrDCPUpFBgiLoWRtdrRpBLKaLFQYn4cPIOrsG3++s pcEtVPr2cCmHyLRM23EETkUaD7IwWdEB/7b2gKWnLO3H9UGQRVcV58AZ2QlsSZxh Ll74vH1FF35GOp2LDMh57oWrr8tONwKPBdCZlv6yWRW0LXw2/v9kNAmpweXd5So= =tTqZ -----END PGP SIGNATURE----- --Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526--