Core & Registration errata 2 incompatible with JAR

[Filip Skokan]

The errata 2 drafts for Core and Dynamic Registration allow http to be used for request_uri (and request_uris in dynamic registration) where before this was https only. This is allowed only under the condition that the loaded Request Object is verifiable by the OP - signed and/or symmetrically encrypted.

Note: I couldn't find the discussion leading to this change.

JAR in its current draft on the other hand allows only https URIs and URNs.

The "request_uri" value MUST be either URN as defined in RFC8141 or "https" URI as defined in 2.7.2 of RFC7230.

• https always
• http if the resulting object is verifiable
• urn if there's a resolver implemented on the OP side

I get and support all three schemes but maybe the specs should align on this.

[Michael Jones]

This update was made in draft -24 19 months ago as a result of a working group discussion. I may be able to find the discussion before the next call.

[Michael Jones]

BTW, I wouldn't say that it's incompatible. JAR is a restriction of the Connect request object logic. As such, all JAR deployments would also be legal Connect request object deployments.

[Filip Skokan]

This update was made in draft -24 19 months ago as a result of a working group discussion. I may be able to find the discussion before the next call.

Thanks, i'll try to do some digging then.

BTW, I wouldn't say that it's incompatible

Incompatible may be a strong wording yes.

As such, all JAR deployments would also be legal Connect request object deployments.

Not a 100% tho.

• https - OIDC Errata 1
• https, **http** - OIDC Errata 2
• https, **urn** - JAR draft 17

Feel free to close if you don't think this worth aligning.

[Michael Jones]

Closing with no action, per the 31-Jan-19 working group call.