Add explicit statement that nonce endpoint is not protected by an access token

[jogu]

As far as I can see we don't actually explicitly say that the nonce endpoint is not an oauth protected resource. We probably should, more than one participant in the interop seem to have assumed it is.

[bc-pi]

An credential issuer implementation/deployment could choose to make it protected by an access token though, right? And could do so by challenging with a 401 + WWW-Authenticate.

I guess what I'm saying is that any such explicit statement should probably say that it isn't required to be protected but should avoid prohibiting doing so.

[jogu]

Hm, interesting. Many people seem to be of the opinion it isn't protected, and I definitely remember a WG discussion where we agreed not to protect it for now & revisit if people did have cases where it needs to be a protected resource, but I agree what you said also isn't explicitly outlawed.

Whatever the outcome is, it's definitely good to clarify it in the spec text, if for no other reason than so we correctly test all the relevant cases in the conformance suites :)

[tplooker]

I guess what I'm saying is that any such explicit statement should probably say that it isn't required to be protected but should avoid prohibiting doing so.

I'm a bit 50/50 on this, while I can see the merit in potentially preserving this for future definition, if implementations started doing this in a non-standard way it would have impacts on interoperability right?

[jogu]

@tplooker exactly.

Or put another way, if we don't make a choice in VP, we likely need to make a choice in HAIP.

[bc-pi]

I guess what I'm saying is that any such explicit statement should probably say that it isn't required to be protected but should avoid prohibiting doing so.

I'm a bit 50/50 on this, while I can see the merit in potentially preserving this for future definition, if implementations started doing this in a non-standard way it would have impacts on interoperability right?

I don't have a dog I want to send up this hill to be in the fight but I don't think using a standard response header with a standard HTTP response code quite qualifies as "non-standard". Might it impact interoperability? Yeah, it might. Should the text mention the possibility so as to improve potential interoperability? I dunno, maybe. Should the nonce endpoint just be made to require an access token (a la #461)? I dunno, that seems perfectly reasonable to me too. I asked about the idea when the nonce endpoint was first introduced and the initial reaction (it's probably in the minutes someplace) seemed to be largely that folks preferred not to require an AT. So that's what I did as the path of least resistance. And I understand that some folks still seem to be against it. But I'm having a hard time seeing what the harm would be. Or should the text prohibit the endpoint ever requiring an AT? Maybe, I dunno, ask the dog that's not in this fight.

[tplooker]

speaking to the dog that's not in this fight

"Non-standard" was a poor choice of words, what I was meaning to imply was that if an AS started requiring an AT to hit its nonce endpoint and there was no way for a wallet implementation to know about this constraint, nor was there any expectation from the specification that the wallet implementer needed to supply an AT, then interoperability would be affected. So either way we should at least clarify that.

[tlodderstedt]

I suggest to clarify the spec expects the nonce endpoint can be called without an access token. If we don't do it here, we should do it in HAIP (at least).