❓ Should DIDRequestOptions contain a property that allows clients to specify which verificationMethod types they support?
Hopefully not? don't know enough about how often only one is supported
The RFC afaik does not currently specify which verificationMethod (authentication, assertionMethod) should be used for this did.request method. Based upon the quoted text above, it seems at least that callers shouldn't be allowed to specify (which I agree to), but should it be authentication always then?
❓ Should user consent show the challenge sent by the client?
Yes, users should always see what they are signing. The challenge can be displayed in dimmed and smaller text in wallets that want a cleaner interface, but I think it should be shown so users don't sign arbitrary messages.
❓ is there too much overlap with DIDAuthn?
No, I'm actually working on an authentication implementation that relies only on did.request and generates a server-side JWT that is set on HTTP-only cookie. It's just an quick and easy way to do authentication.
The RFC afaik does not currently specify which verificationMethod (authentication, assertionMethod) should be used for this
did.requestmethod. Based upon the quoted text above, it seems at least that callers shouldn't be allowed to specify (which I agree to), but should it beauthenticationalways then?Yes, users should always see what they are signing. The challenge can be displayed in dimmed and smaller text in wallets that want a cleaner interface, but I think it should be shown so users don't sign arbitrary messages.
No, I'm actually working on an authentication implementation that relies only on did.request and generates a server-side JWT that is set on HTTP-only cookie. It's just an quick and easy way to do authentication.