Thanks Vladmir,
Here are my answers to your comments:
A1. No, we have not thought about it. Interesting idea though.
A2. "Resource content" here means the binary response that you get from the
URI.
This mechanism was put in here to enforce that different response from the
request_uri will mean different URI. Perhaps, we should just say that
if the content is changed, the URI MUST change.
A3. Content of the request_uri MUST be a request object, which is a JWT,
which is UTF-8.
Cheers,
Nat
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of Vladimir Dzhuvinov
Sent: Monday, August 1, 2016 3:25 AM
To: [email protected]
Subject: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-07: Support for other
grants, charset
I have a few comments on the signed requests draft:
1. Have there been thoughts on extending the request JWT concept to other grant
types, e.g. password and client_credentials? The ability to seal selected
request parameters could prove useful there too.
2. The SHA-256 hash is computed over the "resource contents", i.e. not over the
JWT [1]. Does this mean that line breaks and white space intended for improving
human readability is OK? Perhaps this should be mentioned explicitly.
3. I see that no particular charset for the resource contents referenced by the
request_uri is mandated, and there is no mention that the web server should
indicate the charset. I suppose this was meant to make JWT deployments /
uploads easier. However, this may also lead to problems if the AS tries to
validate the SHA-256 hash and doesn't know what charset was used (is anyone
actually expected to be validating the fragment if
present?) JWT (RFC 7519) is explicit on UTF-8 though.
Thanks,
Vladimir
[1] https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-07#section-4.2
--
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
