Yes, the request object is JWT-based, but the request URI is not. In other
words, you can post a JWT but what you get back is a URI, not the JWT itself.
The request URI was always meant to be a reference, and originally it was
explicitly a reference to a signed request object.
— Justin
On Sep
Following up from the discussion in Montreal, we’ve created the
non-working-group mailing list TXAuth to start discussion of transactional
authorization work. Please join the list here:
https://www.ietf.org/mailman/listinfo/txauth
We’ve also proposed a BoF for Singapore. The details of the agen
> The URI is intended to be a reference not a value. If the client could send a
> JWT it would just send a request object instead of a request URI in the first
> place. So the intent is that it’s random, and maybe we should just say that
> explicitly.
I thought this language was explicitly to a
This is absolutely something that needs to be mentioned in the
security & privacy considerations.
My worry is that by leading with an example of account numbers in the
request URL, we're sending the wrong message.
I do see the value in rich authorization requests with no PII like
George described
Aaron, some comments inline.
— Justin
On Sep 26, 2019, at 8:30 AM, Aaron Parecki
mailto:aa...@parecki.com>> wrote:
Hi Torsten,
I'm very glad to see this draft, I think it's definitely needed in
this space. Here are some of my thoughts on the draft.
"request_uri": "urn:example:bwc4JK-ESC0w8acc
I agree with George that this is a good fit for a security consideration, not a
normative requirement. While it’s best to always protect the request data, this
isn’t all that much different from having scopes that might leak personal
information. Like for example, asking for access to HIV inform
This is a great point about personal information. However, there are
uses for authorization_details that don't specifically relate to
personal information. Think an enhancement that has language preference,
maybe a device identifier. Maybe we can add more text in the security
considerations sec
Hi Torsten,
I'm very glad to see this draft, I think it's definitely needed in
this space. Here are some of my thoughts on the draft.
> "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"
Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*
Hi Torsten,
Overall I am a fan of a way to provide more structure in authorization
requests, and I'm excited to see this draft, so thanks for that.
I do have some concerns about one aspect of this. Given its clear
intended use as a way to create authorization requests to do things
like transfer m
Hi all,
I've revised the browser-based apps draft to take into account
everything discussed at the previous IETF meeting in Montreal.
https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04
Here's a summary of the changes:
* Disallow the password grant to bring it inline with the Sec
Some feedback on this draft compared to the last one that I read:
* The acronym RS and the term "resource server" are used
inconsistently. It would read better IMO if the acronym was always
used after being defined or if resource server was always spelled out.
Same for AS, but less so. Maybe this
11 matches
Mail list logo
