discontinue ad hoc and inappropriate use of "OAuth URI"s

[bc-pi]

update the URIs somehow used with VCDM's termsOfUse to somehow indicate conformance to "those" specified in OpenID Federation and something about trust marks or whatever to something at least somewhat less wrong and not needing a permanent registration in an almost wholly unrelated IANA registry

https://www.rfc-editor.org/rfc/rfc6755.html

related to #274

[selfissued]

Does anyone know what the procedure for registering urn:openid is?

[bc-pi]

Does anyone know what the procedure for registering urn:openid is?

There isn't one.

[selfissued]

I think the registration procedure is described at https://www.rfc-editor.org/rfc/rfc8141.html#section-6.

[bc-pi]

Sorry, I misread the question as what the procedure is for registration of something under urn:openid, for which I don't think there is anything.

As far as registering a general namespace like urn:openid, I don't honestly know for sure. RFC 8141 might be applicable. Maybe. That would seem to be something for the OpenID Foundation as a whole should pursue, should it be deemed useful or of interest to the work of the foundation.

At least one OIDF final standard has utilized URIs with an openid namespace already and there have been no consequences to the best of my knowledge.

Specifically, https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html uses:
urn:openid:params:grant-type:ciba
urn:openid:params:jwt:claim:auth_req_id
urn:openid:params:jwt:claim:rt_hash

[selfissued]

I'd be fine putting these URIs in the urn:openid:params namespace.

[Sakurann]

@bc-pi I am sorry, what is the biggest problem with using urn:ietf:params:oauth:? openid4vp claims to be an extension of oauth, so keep using urn:ietf:params:oauth: feels less work in terms of registerng new urn:openid, etc.

[bc-pi]

@bc-pi I am sorry, what is the biggest problem with using urn:ietf:params:oauth:? openid4vp claims to be an extension of oauth, so keep using urn:ietf:params:oauth: feels less work in terms of registerng new urn:openid, etc.

urn:openid isn't going to be registered so this is less work and doesn't enshrine this stuff in a permanent registry

[bc-pi]

see also #274 (comment) and #274 (comment)

[selfissued]

Works for me

[Sakurann]

@bc-pi why is there no need to register urn:openid?

[jogu]

@Sakurann

@bc-pi why is there no need to register urn:openid?

As I think Brian's away the next few days I'll make the guess that I think what he was saying is that there's no IANA registry that exists today that we would need to register urns beginning urn:openid into. And even if we did register openid at https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml#urn-namespaces-2 I don't think there's any requirement that the registry for urn:openid is run by IANA. (And as Brian mentioned above, https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html already uses urn:openid values so there's precedent for using them and not needing to register them anywhere)

[Sakurann]

from a name collision perspective, using a registration would be better. if we think no one will ever use these URNs, the better solution is to remove the section that uses these URNs than trying to go around the registration?

I am just saying that sounds like the problem is bigger than whether there is a need to register a urn value or not.

[jogu]

@Sakurann

from a name collision perspective, using a registration would be better.

a urn:openid: value created in an openid foundation spec is pretty close to being collision proof. If we really think it's important we could formally register 'openid'.

if we think no one will ever use these URNs, the better solution is to remove the section that uses these URNs than trying to go around the registration?

I am just saying that sounds like the problem is bigger than whether there is a need to register a urn value or not.

As an attempt to make any kind of progress, I've created an alternative pull request that removes the values instead:

#280

[Sakurann]

superseded by #282