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

Justin Richer <jricher@mit.edu> Mon, 01 December 2014 02:57 UTC

Return-Path: <jricher@mit.edu>
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 CF3151A0393 for <oauth@ietfa.amsl.com>; Sun, 30 Nov 2014 18:57:37 -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 xkFyp0CMJZsN for <oauth@ietfa.amsl.com>; Sun, 30 Nov 2014 18:57:34 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E521A020A for <oauth@ietf.org>; Sun, 30 Nov 2014 18:57:34 -0800 (PST)
X-AuditID: 12074423-f79b86d000000cf5-10-547bd91c2504
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 73.22.03317.D19DB745; Sun, 30 Nov 2014 21:57:33 -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 sB12vWwr010922; Sun, 30 Nov 2014 21:57:32 -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 sB12vSLj001610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 30 Nov 2014 21:57:30 -0500
Content-Type: multipart/signed; boundary="Apple-Mail=_670C1025-4F13-4B99-B159-14BA77BAB895"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <BN3PR0301MB12348944618D97E9C2B87E6EA67C0@BN3PR0301MB1234.namprd03.prod.outlook.com>
Date: Sun, 30 Nov 2014 21:57:26 -0500
Message-Id: <375CE45E-8896-4BD1-B398-ECE53A464BF7@mit.edu>
References: <BN3PR0301MB12348944618D97E9C2B87E6EA67C0@BN3PR0301MB1234.namprd03.prod.outlook.com>
To: Anthony Nadalin <tonynad@microsoft.com>
X-Mailer: Apple Mail (2.1878.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRmVeSWpSXmKPExsUixCmqrSt7szrEYPE0douTb1+xWWyau43R gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGVsv5tSsHsiY8W7s5eYGhhn1HQxcnJICJhI zHz+ix3CFpO4cG89WxcjF4eQwGImibuXL7GAJIQENjJK/DqTCpG4ySTRcOc7C4jDLDCJUWJu 022wdl4BA4kluzYxg9jCAmYS65a2sIHYbAKqEtPXtDCB2JwCiRLbz00Asjk4WIDi3xtkQMLM QOaXBe+ZIMZYSRw+dQhqcYLExN4pYCNFBLQlTrxfyQxxqbzEhw/H2ScwCsxCdsYsJGfMApub JDH12RUWCFtbYtnC11BxA4mnna9YMcX1Jd68m8MEYctLbH87BypuKbF45g2oObYSt/oWQNXY STyatoh1ASP3KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0zvdzMEr3UlNJNjKBYY3dR3sH456DS IUYBDkYlHl6J+dUhQqyJZcWVuYcYJTmYlER5T88DCvEl5adUZiQWZ8QXleakFh9iVAHa9WjD 6guMUix5+XmpSiK85zyA6nhTEiurUovyYcqkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAo SfA+uQ7UKFiUmp5akZaZU4KQZuLgPMQowcEDNPwVSA1vcUFibnFmOkT+FKOilDjvU5CEAEgi ozQPrheWIl8xigO9JcxrfgOoigeYXuG6XwENZgIazNBcCTK4JBEhJdXAeODH9YCpFcv9dhpk RxTXZjU8ibl2T/6ExLmIWeLvYwKyBedwvgg508G7ZKv435ZvaVLqlf/2770zperY0sTo3yqP jdmn/UuIbD39vFCmVlMpx+zayaMHVb+HXtn9UHUP0+4/LcovbU4Iqrg0vKpY41SU+ON0v0pJ RJ6BVdjq2yHnb0ddaK1IU2Ipzkg01GIuKk4EAJs7HGFsAwAA
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kaZOkDkNaKZQfFihqJo2emEmNOo
Cc: "oauth@ietf.org" <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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2014 02:57:38 -0000

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’ve just posted the updated draft, and I think that you’ll 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
> “about the authentication conext”, 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 “OAuth 2.0” throughout the document, let me know if I missed any.

> “allows holder of a token to query” 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”, 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 – is this any type of token ? how does the endpoint know that it can deal with this token type?

Clarified that it’s 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’s 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’s 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’ve 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’t see the point of introspecting an authorization code — those aren’t sent to protected resources, they’re sent to clients, which would in turn just hand it to the token endpoint to get a token. There’s 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’ve 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’t 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’ll have to do the same thing with the Revocation RFC.

>  Introspection Response
> What is “active” mean ? Is this up to the server to determine ?

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

> “scope OPTIONAL”, is this the scope in the token or is this the scope that the introspection endpoint sources may have ? It’s 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’t good, that’s still a 200 response — the request is fine, but the token being introspected isn’t active, which is what’s returned. This isn’t an error, it’s a valid answer to the question of “what is this token?” that’s being asked every time introspection is called.

> Can the endpoint return a encrypted response ?

That’s 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’t A Thing when this draft was first written.

 — Justin

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