While testing our OpenID4VP implementation with the Microsoft Authenticator app (Verified ID) with did:web, we found out that the Microsoft Authenticator app does not support did:web with subpaths. Apparently deliberately, since it fails with an explicit error message. This is most probably for security reasons: it's much easier to upload/serve a file from a (deep) subpath on a domain (e.g. upload a did.json file on a shared Wordpress host), than to put it into a web server's root directory. If the resolving party would derive trust from the domain name, this trust could be misplaced.
Registrations MAY also contain additional information, such as the
syntax of additional path components, query strings, and/or fragment
identifiers to be appended to the well-known URI, or protocol-
specific details (etc)
This could translate to did:web:example:user:bob being queried from https://example.com/.well-known/did.json/user/bob.
Although it might look weird (file name somewhere in the middle of the URL path), it allows subpaths while (mostly) mitigating the threat of malicious users of the system uploading did:web documents?
While testing our OpenID4VP implementation with the Microsoft Authenticator app (Verified ID) with
did:web
, we found out that the Microsoft Authenticator app does not supportdid:web
with subpaths. Apparently deliberately, since it fails with an explicit error message. This is most probably for security reasons: it's much easier to upload/serve a file from a (deep) subpath on a domain (e.g. upload adid.json
file on a shared Wordpress host), than to put it into a web server's root directory. If the resolving party would derive trust from the domain name, this trust could be misplaced.Did you consider putting
did:web
with paths under the/.well-known
directory as well? RFC 8615 allows additional paths after the well-known identifier (https://datatracker.ietf.org/doc/html/rfc8615#section-3):This could translate to
did:web:example:user:bob
being queried fromhttps://example.com/.well-known/did.json/user/bob
.Although it might look weird (file name somewhere in the middle of the URL path), it allows subpaths while (mostly) mitigating the threat of malicious users of the system uploading
did:web
documents?