What if PAR would use another parameter? It could even return the actual authorization URL.
> On 30. Sep 2019, at 08:45, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: > > > > On Thu, Sep 26, 2019 at 10:50 AM Justin Richer <jric...@mit.edu> wrote: >> If, for whatever reason, it is required that this value is >> actually a URI, is there some expected namespace to use other than >> "example"? I worry that if all the examples in the spec are just >> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up >> using the text "example" because they don't understand why it's there, >> and then it serves no purpose really.’ > > This field must be a URI, as per JAR: > > request_uri The absolute URI as defined by RFC3986 [RFC3986 > ] that > points to the Request Object ( > Section 2.1 > ) that holds > authorization request parameters stated in > section 4 > of OAuth 2.0 > [ > RFC6749 > ]. > > Somewhat awkwardly, the JAR spec currently states that the AS has to do an > HTTP GET on the request URI, so that will need to be fixed in JAR before it > goes forward. I don’t think that was always the case though, and I’m not sure > how that changed. > > JAR does have a somewhat awkward allowance for not doing a GET in > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3 saying > an AS "MUST send an HTTP "GET" request to the request_uri to retrieve the > referenced Request Object, unless it is stored in a way so that it can > retrieve it through other mechanism securely." > > So I'm guessing maybe nothing actually changed but it's just hard to find in > the document. > > > As for the namespace, “example” is ok for an example URN. The problem with > URNs is that nobody really understands how to do domain-safe fully compliant > URNs. So perhaps we should instead use “urn:fdc:example.com:….” Instead (as > per https://tools.ietf.org/html/rfc4198). > > Something else to consider additionally or alternately is that the document > could provide some suggestions/guidance or even requirements on the structure > of the URN for this self referential case. It could, for example, use the > RFC6755 subnamespace and registry and be of the form > urn:ietf:params:oauth:request_uri:<handle> or > urn:ietf:params:oauth:request_uri;<handle> or > urn:ietf:params:oauth:request_uri?value=<handle> or > urn:ietf:params:oauth:request_uri#<handle> or however the proper way to do > that would be. > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.. If you have > received this communication in error, please notify the sender immediately by > e-mail and delete the message and any file attachments from your computer. > Thank you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
