From a security POV please force HTTPS as we see in 5.2.1. The only performance problem with HTTPS is that it's not used enough. There is no good reason for a security framework to support HTTP.
Aloha, Jim > On Mar 24, 2017, at 9:15 AM, Dave Tonge <dave.to...@momentumft.co.uk> wrote: > > Hi Nat and John > > I have some questions re the JWT Secured Authorization Request spec > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12 > > 1. Does the request_uri always have to be an URL? > If the request object is hosted by the client then it makes sense, but if > 10.3.d is followed and the AS provides an endpoint where the client can > exchange a request object for a "Request Object URI" then it would seem > acceptable for that uri to be an urn. Only the AS would need to be able to > fetch the request object and therefore there would be no need for the request > object to be made available via https. > > 2. Should the mechanism described in 10.3.d be explained in 5.2? > I think that 10.3.d could be widely used as it solves a number of problems - > however it is currently not clearly defined in either OIDC Core or jwsreq. > > 3. The spec seems inconsistent on the use of HTTPS > Subject to any discussion re request_uris always being urls, there seems to > be an inconsistency between 5.2 and 5.2.1 > > 5.2: > The scheme used in the "request_uri" value MUST be "https", > unless the target Request Object is signed in a way that is > verifiable by the Authorization Server. > > 5.2.1 > The Client stores the Request Object resource either locally or > remotely at a URL the Authorization Server can access. The URL MUST > be HTTPS URL. This URL is the Request Object URI, "request_uri". > > > Thanks > > -- > Dave Tonge > CTO, Momentum Financial Technology > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
