Hannes,
Yes, disambiguation with JWT is a very important goal here, since both
are talking about token information. The document currently has this
text in 3.1.1:
Name:
The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted. Names that match
claims registered in the JSON Web Token Claims registry
established by [JWT
<http://tools.ietf.org/html/draft-ietf-oauth-introspection-07#ref-JWT>] SHOULD
have comparable definitions and
semantics.
But perhaps we can push this even further. Additionally, the review list
is the oauth-ext list, but perhaps it should be jwt-ext in addition or
instead of oauth-ext. I'd like WG feedback on that aspect as well.
-- Justin
On 3/31/2015 5:30 AM, Hannes Tschofenig wrote:
Hi Justin,
thank you for quickly updating the document to give the working group a
chance to review the proposed text for the open issue regarding the
registry.
We should give the group a couple of days to decide whether they like
the change.
I looked at the text and it is fine with me. I was, however, wondering
whether the expert reviewers should be given some guidance. For example,
I could imagine that it would be helpful to check a new claim against
the JWT registry. What we would like to avoid is to have claims in the
introspection registry that have the same name but a different semantic
compared to those in the JWT registry. That could lead to a lot of
confusion.
Ciao
Hannes
On 03/28/2015 12:28 AM, Justin Richer wrote:
This version creates the OAuth Token Introspection Response registry as
discussed at the face-to-face meeting this past Monday. This is a new, separate
registry from the JWT registry, and it wholesale imports the claims in the JWT
registry as response elements. There are instructions in the registry’s
template and description about manually coordinating with the contents of the
JWT registry, which will ultimately be the responsibility of the expert
reviewers.
Please check the diffs and the final version to make sure that this makes
sense, and I’d like to hear feedback from the wider working group to confirm
that this is the direction we want to take vis a vis the response parameters.
— Justin
On Mar 27, 2015, at 6:23 PM, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Token Introspection
Author : Justin Richer
Filename : draft-ietf-oauth-introspection-07.txt
Pages : 16
Date : 2015-03-27
Abstract:
This specification defines a method for a protected resource to query
an OAuth 2.0 authorization server to determine the active state of an
OAuth 2.0 token and to determine meta-information about this token.
OAuth 2.0 deployments can use this method to convey information about
the authorization context of the token from the authorization server
to the protected resource.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-introspection-07
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-07
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
