> Title : OAuth 2.0 Token Exchange: An STS for the REST of Us
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05
This spec has some useful functionality, but comes across as a tad conceited.
Suggestions:
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.
FROM:
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
TO:
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
REQUIRED. An identifier of either:
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
