Skip to content

Make https binding mandatory for network-based did resolvers #272

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ottomorac wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Make https binding mandatory for network-based did resolvers #272

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 12 additions & 9 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,7 +131,7 @@
Decentralized identifier (DID) resolution is the process of obtaining
a DID document and accompanying metadata for a specific DID. The process
takes a DID and a set of resolution options as its input and returns a
DID document and associated metadata about the resolved document and the
DID document and associated metadata about the resolved document and the
resolution request. A resolved DID document is a set of information which
enables cryptographically verifiable interactions with the DID subject,
including mechanisms such as cryptographic public keys. This specification
Expand Down Expand Up @@ -448,9 +448,9 @@ <h3>Datetime</h3>

<p>
All datetime values in this specification MUST be an <a data-lt="ascii string">
ASCII string</a> which is a valid XML datetime value defined by the
[[VC-DATA-MODEL]] in <a data-cite="vc-data-model#representing-time"></a>.
Additionally, timestamps used in DID Resolution MUST be adjusted to UTC
ASCII string</a> which is a valid XML datetime value defined by the
[[VC-DATA-MODEL]] in <a data-cite="vc-data-model#representing-time"></a>.
Additionally, timestamps used in DID Resolution MUST be adjusted to UTC
without sub-second decimal precision. For example: <code>2020-12-20T19:17:47Z</code>
</p>

Expand Down Expand Up @@ -582,7 +582,7 @@ <h3>DID Resolution Options</h3>
value to determine the <a>representation</a> of the returned
<code>didDocument</code> if such a <a>representation</a> is supported and
available. Any <a>representation</a> MUST be able to be translated into
the representation defined by the <code>application/did</code> mediaType.
the representation defined by the <code>application/did</code> mediaType.
This property is OPTIONAL.
</dd>
</dl>
Expand Down Expand Up @@ -1593,11 +1593,7 @@ <h2>Metadata Structure</h2>
<a data-cite="INFRA#sets">set</a>,
<a data-cite="INFRA#boolean">boolean</a>, or
<a data-cite="INFRA#nulls">null</a>. The values within any complex data
<<<<<<< HEAD
structure such as a map or list MUST be one of these data types as well.
=======
Comment on lines -1596 to -1598
Copy link
Contributor

@wip-abramson wip-abramson Jan 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooops, not sure how this got in. But quite possibly my fault

structure such as a map or list MUST also be one of these data types.
Copy link
Member

@TallTed TallTed Jan 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This concern is also seen in a very similar issue/PR. MUST also be one of these data types says to me that the values within any complex data structure such as a map or list MUST also be a complex data structure such as a map or list or similar, rather than permitting the simple data structures previously listed. I suggest just repeating the list, for clarity, even though it lengthens the paragraph.

>>>>>>> 526ac87 (Apply suggestions from code review)
The entire metadata structure MUST be serializable according to the <a
data-cite="INFRA#serialize-an-infra-value-to-json-bytes">JSON
serialization rules</a> in the [[INFRA]] specification. Implementations MAY
Expand Down Expand Up @@ -2303,6 +2299,13 @@ <h2>HTTP(S) Binding</h2>
<p>This binding is generally considered a <a>remote binding</a>, but could
also be a <a>local binding</a> if the HTTP(S) endpoint is run in a local environment, such as on <code>localhost</code>.</p>

<p>
All <a href="#dfn-conforming-network-based-did-resolver">conforming DID resolvers</a> MUST implement the GET version of the
<a href="#bindings-https">HTTPS binding</a> and MAY implement the POST version.
All <a href="#bindings-https">HTTPS bindings</a> MUST use TLS. Use of DNS names
in certificates is NOT REQUIRED; resolvers MAY use TLS certificates issued for IP addresses.
Comment on lines +2303 to +2306
Copy link
Member

@msporny msporny Jan 22, 2026 •
edited by wip-abramson
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
All <a href="#dfn-conforming-network-based-did-resolver">conforming DID resolvers</a> MUST implement the GET version of the
<a href="#bindings-https">HTTPS binding</a> and MAY implement the POST version.
All <a href="#bindings-https">HTTPS bindings</a> MUST use TLS. Use of DNS names
in certificates is NOT REQUIRED; resolvers MAY use TLS certificates issued for IP addresses.
All <a href="#dfn-conforming-network-based-did-resolver">conforming network-based DID resolvers</a> MUST implement the GET version of the
<a href="#bindings-https">HTTPS binding</a> and MAY implement the POST version.

</p>

<p>Using this binding, the <a>DID resolution</a> function (see
<a href="#resolving"></a>) and/or <a>DID URL dereferencing</a> function (see <a href="#dereferencing"></a>)
can be executed as follows:</p>
Expand Down