Thank you, James, for the review and feedback. I apologize for the slow
reply - on top of being a busy week this was a difficult one to respond to.
It's disappointing to hear that it came off as conceited. That certainly
wasn't the intent (though I suppose it rarely is).
While I think there's plenty of precedent in things calling themselves
lightweight, whether or not it's justified, and do believe this is light
enough to warrant the use of the term, I am open to dropping "heavyweight"
and "lightweight", if you think it would improve the tone of the text.
The title is something I'm less open to changes on. Honestly, I'm really
partial to it. I described it as "really really important" on slide 7 of the
IETF 93 presentation about token exchange
<https://www.ietf.org/proceedings/93/slides/slides-93-oauth-0.pdf> and
tried to brake it down humorously in a recent identity conference
presentation
<http://www.slideshare.net/briandavidcampbell/oauth-20-token-exchange-an-sts-for-the-rest-of-us/7>.
I've had numerous positive comments about it from people who appreciate the
little touch of humor. I anticipate there may be some push-back in later
stage reviews on the unexpanded acronym but I'll cross that bridge when/if
I come to it and look to find some compromise.
The "access_token" member/parameter is required per RFC 6749 so it has to
be in the response anyway and seemed like a suitable bucket for the
returned token even when the token isn't strictly an access token. What's
an alternative, putting some dummy value in "access_token" and returning
the requested token under a different name? You mention ID Tokens, which is
a potentially interesting case as there's already sort of a way to
additionally request an ID Token by using the "openid" scope. Perhaps there
should be some discussion or guidance on that? I think that might even be
helpful for something Tony has made statements about (maybe).
Generally I think that it's a little too late to be changing parameter
names like xxxx_token_type to xxxx_token_context. Unless there's
overwhelming support from others for such a change. I do think the way that
you've articulated the distinction between tokens from other parties and
tokens from this AS is useful and I'll endeavor to add and/or adjust some
text along those lines to further clarify.
On Sun, Jul 10, 2016 at 8:13 PM, Manger, James <
Post by Manger, JamesPost by i***@ietf.orgTitle : OAuth 2.0 Token Exchange: An STS for the REST
of Us
Post by i***@ietf.orghttps://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05
This spec has some useful functionality, but comes across as a tad conceited.
1. Drop "An STS for the REST of Us" from the title.
"STS" is not common enough to be unexpanded. The protocol isn't a
poster-child for RESTful design; as the 3rd paragraph of the introduction
explicitly says ("the STS protocol defined in this specification is not
itself RESTful"). Hopefully it is easier for developers than the WS-*
suite, but it is from some of the same companies and for some similar
purposes so "for the rest of us" doesn't really ring true (though it is a
cute play on words).
2. Drop "lightweight" from the abstract.
Stick to the facts: an HTTP+JWT+JSON-based STS, as an alternative to an
HTTP+SOAP+XML-based STS.
3. Drop "heavyweight" and "lightweight" from the introduction.
Web Service clients have used WS-Trust
[WS-Trust] as the protocol to interact with an STS for token
exchange, however WS-Trust is a fairly heavyweight protocol, which
uses XML, SOAP, etc. Whereas, the trend in modern Web development
has been towards lightweight services utilizing RESTful patterns and
JSON.
... This specification defines a lightweight protocol extending OAuth 2.0
Web Service clients have used WS-Trust
[WS-Trust] as the protocol to interact with an STS for token
exchange. While WS-Trust
uses XML and SOAP, the trend in modern Web development
has been towards RESTful patterns and
JSON.
... This specification defines a protocol extending OAuth 2.0
Requiring "only an HTTP client and JSON parser" is nice for some
developers over requiring an XML/SOAP parser. But to warrant the
"lightweight" tag the spec need to mention major design ideas from WS-Trust
that are deliberately dropped from OAuth-2.0-Token-Exchange (and will not
need to be added later).
4. Do we really need to put a non-access-token (eg an id-token) in a field
named "access_token", then override that with
"issued_token_type":"urn:ietf:params:oauth:token-type:id_token"?
5. I'm suspect I'm far too late to the party to comment on token_type vs
{subject|requested|actor|issued}_token_type, but surely we can do better
than create the confusion in this spec. I think the issue is that we want
to support tokens from other parties and tokens from this AS. For the
former we need to indicate the syntax (eg JWT or SAML) so the AS can parse
it; for the latter we need to indicate what the AS issued it for (eg
access_token or refresh_token) so the AS can look it up in the correct DB.
SUGGESTION: Rename xxxx_token_type to xxxx_token_context.
subject_token_context
the syntax of the token (when issued from another AS) so the AS
knows how to parse it;
or the sort of token it is (when issued by this AS). See section 3.
Adjust other xxxx_token_context definitions, and section 3.
--
James Manger
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth