Add support for initial-state #23

dhh1128 · 2020-08-29T18:32:24Z

Signed-off-by: Daniel Hardman daniel.hardman@gmail.com

Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>

dhh1128 · 2020-08-29T18:34:00Z

Tagging @peacekeeper and @csuwildcat and @OR13 and @TelegramSam and @swcurran . This is my proposed update to peer DIDs that would make support for initial-state official. My intention was to align as much as possible with how initial-state is imagined to work in ION and so forth -- but the docs I could find about that seemed a bit stale. So I may have diverged slightly. Can you review?

kdenhartog · 2020-08-31T04:20:58Z

core.html

@@ -169,6 +169,8 @@ <h2>Recognizing and handling peer DIDs</h2>
        capture group 1, <code>transform</code> in capture group 2, and <code>encnumbasis</code> in capture group 3.
    </p>

+    <p>Note that peer DIDs can also be used in DID URIs, with query parameters. Currently, the only query parameter formally defined for peer DIDs is <code>initial-state</code>, discussed <a target="#initial-state">below</a>. However, other parameters may be used by a given implementation, so recipients of a peer DID URI should at least be prepared to parse the DID into its base DID value and its query string portion (which begins with the <code>?</code> character. All query parameter values in peer DID URIs are base64url encoded.</p>


Are you planning to just use the default version-time stuff from did-core which is why we have this statement: "Currently, the only query parameter formally defined for peer DIDs is initial-state," because technically this method only defines one. However, we would expect implementations to use some if not all of the query parameters defined in did-core.

Ooh, good catch.I will remove the "only query parameter" language.

I think peer dids need to support version stamping. I don't know about version timing; each party sees evidence for an update accumulate in different orders and at different times. @kdenhartog or @peacekeeper , can you point me to docs on the versioning parameters?

The only documentation I'm aware of is here: https://w3c.github.io/did-core/#generic-did-url-parameters

did-docs.html

kdenhartog · 2020-08-31T04:29:55Z

did-docs.html

+    <p>
+        This places the value of the <code>initial-state</code> parameter in capture group 1.
+    </p>
+    <p>To interpret the parameter value, it must first be base64url decoded. The result MUST be a JSON array containing zero or more deltas. An empty parameter value is also allowed, and is considered equivalent to an empty JSON array.</p>


I'm a bit confused about what you're describing with the JSON array containing zero or more deltas. Is the recipient expected to rebuild the did document from the various deltas provided in the initial-value parameters?

In sidetree just the did document is provided in base64url encoding, but there's no requirements about the canonicalization of the data in the document unlike what would occur with the deltas to get a proper output from the CRDT by the reciever. So, my interpretation is the value of this parameter is slightly different than what's in sidetree, but the end goal is the same (pass the information in a did document as a query parameter)

The peer DID spec differentiates between the stored variant of a DID doc and the resolved variant. The resolved variant is a canonical DID doc. The stored variant is a set of deltas from which a resolved variant can be derived. The deltas are what must be transmitted in initial state, not the rendered doc.

OR13 · 2020-08-31T13:24:06Z

Here is my documented signed-ietf-json-patch... https://github.com/decentralized-identity/did-spec-extensions/blob/master/parameters/signed-ietf-json-patch.md

its got test vectors and a spec, and it lets you decide how you want to interpret a "mutation" to a did documents, represented as a URI...

initial-state is of undefined type... and is therefore... pretty hard to document well...

@dhh1128 I suggest considering signed-ietf-json-patch instead, or... using that spec, to generate a value for initial-state... which would be legal, since initial state has not defined value.

dhh1128 · 2020-08-31T15:24:57Z

@OR13 : Converting the deltas strategy of peer DIDs to use signed-ietf-json-patch might be a good idea, but I think it is out of scope for this PR. Let's discuss that as a separate change.

Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>

dhh1128 · 2020-08-31T20:48:35Z

@OR13 I have opened #24 to track your suggestion about using signed-ietf-json-patch. Are you okay with the merge, given that we're tracking that now as a separate topic?

OR13

Looks good, lets continue the discussion about initial-state vs signed-ietf-json-patch on the linked issue.

lacks complete update of the new method in the rest of the document. Signed-off-by: Sam Curren <telegramsam@gmail.com>

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Not yet polished. Signed-off-by: Sam Curren <telegramsam@gmail.com>

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Signed-off-by: George Aristy <george.aristy@securekey.com>

From Kyle Co-authored-by: Kyle Den Hartog <kdenhartog@users.noreply.github.com>

Method 2

…_to_verificationMethod refactor: publicKey -> verificationMethod

fixes spec rendering

…ch-1 fixes spec rendering

Signed-off-by: sklump <srklump@hotmail.com>

…ty-pass typo, regex finesse

fix json syntax

Fix of matching regex and example 4

- Use 2020 verification methods with publicKeyMultibase instead of outdated publicKeyBase58 - Update the main peer DID Doc example: fixed some values, added accept field to services

Fix and Updated DID Doc examples

…er-did-method-spec into fix-service-encoding � Conflicts: � core.html

Signed-off-by: dhh1128 <daniel.hardman@sicpa.com>

Add additional authors

…ice-encoding Fix of service encoding in numalgo2

publicKeyMultibase must contain multicodec prefix (and hence equal to the encnumbasis)

…e-fix Fix peer DID Doc example

Moopli · 2021-12-21T15:23:08Z

@dhh1128 this PR has been sitting for some time, are there any blockers to merging? It's referenced in the DIDComm v2 implementer's guide, and we're looking to use it as the mechanism to share peer DIDs over DIDComm v2 messages, so it would be good to know if this is/isn't the direction the spec will go.

dhh1128 · 2021-12-21T17:26:17Z

Thank you for the ping, @Moopli . I thought this had been merged. There is no impediment to doing so, in my mind.

kdenhartog · 2021-12-21T18:38:14Z

core.html

@@ -169,6 +169,9 @@ <h2>Recognizing and handling peer DIDs</h2>
        capture group 1, <code>transform</code> in capture group 2, and <code>encnumbasis</code> in capture group 3.
    </p>

+    <p>Note that peer DIDs can also be used in DID URIs, with query parameters. Currently, the only query parameter formally defined for peer DIDs is <code>initial-state</code>, discussed <a target="#initial-state">below</a>. However, support for `hl` and `version-id` will be specified soon,


Suggested change

<p>Note that peer DIDs can also be used in DID URIs, with query parameters. Currently, the only query parameter formally defined for peer DIDs is <code>initial-state</code>, discussed <a target="#initial-state">below</a>. However, support for `hl` and `version-id` will be specified soon,

<p>Note that peer DIDs can also be used in DID URLs, with query parameters. Currently, the only query parameter formally defined for peer DIDs is <code>initial-state</code>, discussed <a target="#initial-state">below</a>. Peer DIDs also support `hl` and `version-id` which are defined in <a target="https://www.w3.org/TR/did-core/#did-parameters">DID-Core</a>.

kdenhartog · 2021-12-21T18:40:59Z

core.html

@@ -169,6 +169,9 @@ <h2>Recognizing and handling peer DIDs</h2>
        capture group 1, <code>transform</code> in capture group 2, and <code>encnumbasis</code> in capture group 3.
    </p>

+    <p>Note that peer DIDs can also be used in DID URIs, with query parameters. Currently, the only query parameter formally defined for peer DIDs is <code>initial-state</code>, discussed <a target="#initial-state">below</a>. However, support for `hl` and `version-id` will be specified soon,
+        and other parameters may be used by a given implementation, so recipients of a peer DID URI should at least be prepared to parse the DID into its base DID value and its query string portion (which begins with the <code>?</code> character. All query parameter values in peer DID URIs are base64url encoded without padding (consistent with JOSE conventions).</p>


Suggested change

and other parameters may be used by a given implementation, so recipients of a peer DID URI should at least be prepared to parse the DID into its base DID value and its query string portion (which begins with the <code>?</code> character. All query parameter values in peer DID URIs are base64url encoded without padding (consistent with JOSE conventions).</p>

Other parameters MAY be used by a given implementation, so recipients of a peer DID URL should at least be prepared to parse the DID into its base DID value and its did parameters. All query parameter values in peer DID URLs MUST be base64url encoded without padding (consistent with JOSE conventions).</p>

kdenhartog · 2021-12-21T18:41:53Z

did-docs.html

+    </p>
+    <p>
+        The way to do this is to use the <code>initial-state</code> query parameter of a peer
+        DID URI. All implementations of peer DIDs are required to recognize the meaning of this


Suggested change

DID URI. All implementations of peer DIDs are required to recognize the meaning of this

DID URL. All implementations of peer DID implementations MUST recognize the meaning of this

kdenhartog · 2021-12-21T18:42:28Z

did-docs.html

+        The way to do this is to use the <code>initial-state</code> query parameter of a peer
+        DID URI. All implementations of peer DIDs are required to recognize the meaning of this
+        query parameter, though only implementations that support deltas (layer 2 or 3) need to
+        process it. The parameter value can be extracted from a peer DID URI with the following


Suggested change

process it. The parameter value can be extracted from a peer DID URI with the following

process it. The parameter value can be extracted from a peer DID URL with the following

kdenhartog

Just some minor editorial changes I spotted which should help implementers with interop - the content of the PR still looks good to me and if anything is controversial and you don't want to merge it that's fine. Feel free to leave it off and we can sort it later.

Moopli · 2022-03-29T21:20:14Z

@dhh1128 @kdenhartog we're preparing to release a new version of afgo which uses peer DID initial-state for sharing peer DIDs in DIDComm V2; it looks like this fell through the cracks again, any chance it can be wrapped up and merged, if opinions on it remain the same?

Signed-off-by: dhh1128 <daniel.hardman@gmail.com>

dhh1128 · 2022-03-30T09:01:56Z

I resolved the merge conflicts and can now merge this. However, the reason this languished so long is that @TelegramSam wrote a different algorithm for generating a numeric basis (numalgo=2; see "Method 2" under https://identity.foundation/peer-did-method-spec/index.html#generation-method) that allows someone to specify an initial state (extra keys, endpoint) without using a query parameter. This makes the initial-state stuff partly redundant. The new algorithm is in the implementation of peer DIDs on pypi and the one on Maven Central. So my question is: do we still need this? The feature it unlocks is only different from method 2 in that it can be used with dynamic peer DIDs -- and I'm wondering if anybody actually does that, given that KERI handles dynamism in a more generic way that provides the same guarantees.

peacekeeper · 2022-03-30T09:05:15Z

I can't really comment if this is still needed considering the latest developments in did:peer and KERI, but wanted to mention that we switched to camelCase for DID parameters (including initialState), see here:

Signed-off-by: dhh1128 <daniel.hardman@gmail.com>

dhh1128 · 2022-03-30T09:10:21Z

Thanks for the reminder, @peacekeeper . I have updated the PR to use camelCase.

dhh1128 · 2023-07-17T11:01:57Z

I closed this because it appears that we never got consensus, and it is now very old.

Add support for initial-state

be24691

Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>

kdenhartog reviewed Aug 31, 2020

View reviewed changes

PR feedback: base64url sans pad, other params

3c02a57

Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>

dhh1128 mentioned this pull request Aug 31, 2020

switch delta format #24

Open

OR13 self-requested a review September 1, 2020 14:51

OR13 approved these changes Sep 1, 2020

View reviewed changes

kdenhartog approved these changes Sep 7, 2020

View reviewed changes

llorllale mentioned this pull request Sep 14, 2020

what's new section decentralized-identity/didcomm-messaging#96

Merged

TelegramSam and others added 6 commits January 15, 2021 17:37

Method 3 Initial

f97b972

lacks complete update of the new method in the rest of the document. Signed-off-by: Sam Curren <telegramsam@gmail.com>

Full Multi-key Example

593cb53

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Added purpose indicators

0b41731

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Addition of endpoints

712abc2

Not yet polished. Signed-off-by: Sam Curren <telegramsam@gmail.com>

fixed service encoding

07e6fd3

Signed-off-by: Sam Curren <telegramsam@gmail.com>

refactor: publicKey -> verificationMethod

283a67b

Signed-off-by: George Aristy <george.aristy@securekey.com>

dhh1128 mentioned this pull request Mar 18, 2021

Method 2 #26

Merged

TelegramSam and others added 11 commits March 19, 2021 11:00

Update core.html

0b8a06b

From Kyle Co-authored-by: Kyle Den Hartog <kdenhartog@users.noreply.github.com>

Merge pull request decentralized-identity#26 from TelegramSam/method3

a1f3b2c

Method 2

Merge pull request decentralized-identity#27 from llorllale/publickey…

2f4b4e8

…_to_verificationMethod refactor: publicKey -> verificationMethod

fixes spec rendering

a9a8149

fixes spec rendering

Merge pull request decentralized-identity#29 from brianorwhatever/pat…

f1c40df

…ch-1 fixes spec rendering

typo, regex finesse

b4f200b

Signed-off-by: sklump <srklump@hotmail.com>

Merge pull request decentralized-identity#30 from sklump/sklump-quali…

202a913

…ty-pass typo, regex finesse

fix json syntax

da3c396

Merge pull request decentralized-identity#32 from letmaik/patch-1

b448a49

fix json syntax

fix of regex and example 4

2b2fcca

Merge pull request decentralized-identity#33 from DenisRybas/fix-001

3bbda3b

Fix of matching regex and example 4

ashcherbakov and others added 14 commits September 29, 2021 18:53

Updated examples

6fa62b0

- Use 2020 verification methods with publicKeyMultibase instead of outdated publicKeyBase58 - Update the main peer DID Doc example: fixed some values, added accept field to services

Support "accept" field in services

fd2da4a

fix of service encoding in numalgo2

009dd7c

fix of service encoding in numalgo2

bcc1076

fix of service encoding in numalgo2

997cc29

Mention no padding for bse64 URL safe encoding of services

ee789eb

Merge pull request decentralized-identity#35 from ashcherbakov/master

e7f2447

Fix and Updated DID Doc examples

Merge branch 'master' of https://github.com/decentralized-identity/pe…

dad9ad2

…er-did-method-spec into fix-service-encoding � Conflicts: � core.html

conflicts resolved

9f50801

Add additional authors

d0c3c96

Signed-off-by: dhh1128 <daniel.hardman@sicpa.com>

Merge pull request decentralized-identity#37 from dhh1128/master

eabe65f

Add additional authors

Merge pull request decentralized-identity#36 from DenisRybas/fix-serv…

4fe3eaf

…ice-encoding Fix of service encoding in numalgo2

Fix peer DID Doc example

0e7cc37

publicKeyMultibase must contain multicodec prefix (and hence equal to the encnumbasis)

Merge pull request decentralized-identity#38 from ashcherbakov/exampl…

0f14981

…e-fix Fix peer DID Doc example

kdenhartog reviewed Dec 21, 2021

View reviewed changes

kdenhartog approved these changes Dec 21, 2021

View reviewed changes

dhh1128 added 2 commits March 30, 2022 10:50

apply Kyle's suggestions and resolve merge conflict

f125900

Signed-off-by: dhh1128 <daniel.hardman@gmail.com>

resolve merge conflicts

7affb38

Signed-off-by: dhh1128 <daniel.hardman@gmail.com>

change to camelCase for initialState

4223e00

Signed-off-by: dhh1128 <daniel.hardman@gmail.com>

dhh1128 closed this Jul 17, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for initial-state #23

Add support for initial-state #23

dhh1128 commented Aug 29, 2020

dhh1128 commented Aug 29, 2020

kdenhartog Aug 31, 2020 •

edited

Loading

dhh1128 Aug 31, 2020

dhh1128 Aug 31, 2020

kdenhartog Sep 7, 2020

kdenhartog Aug 31, 2020

dhh1128 Aug 31, 2020 •

edited

Loading

OR13 commented Aug 31, 2020

dhh1128 commented Aug 31, 2020

dhh1128 commented Aug 31, 2020

OR13 left a comment

Moopli commented Dec 21, 2021

dhh1128 commented Dec 21, 2021

kdenhartog Dec 21, 2021 •

edited

Loading

kdenhartog Dec 21, 2021

kdenhartog Dec 21, 2021 •

edited

Loading

kdenhartog Dec 21, 2021

kdenhartog left a comment

Moopli commented Mar 29, 2022

dhh1128 commented Mar 30, 2022

peacekeeper commented Mar 30, 2022

dhh1128 commented Mar 30, 2022

dhh1128 commented Jul 17, 2023

	<p>Note that peer DIDs can also be used in DID URIs, with query parameters. Currently, the only query parameter formally defined for peer DIDs is <code>initial-state</code>, discussed <a target="#initial-state">below</a>. However, support for `hl` and `version-id` will be specified soon,
	<p>Note that peer DIDs can also be used in DID URLs, with query parameters. Currently, the only query parameter formally defined for peer DIDs is <code>initial-state</code>, discussed <a target="#initial-state">below</a>. Peer DIDs also support `hl` and `version-id` which are defined in <a target="https://www.w3.org/TR/did-core/#did-parameters">DID-Core</a>.

	and other parameters may be used by a given implementation, so recipients of a peer DID URI should at least be prepared to parse the DID into its base DID value and its query string portion (which begins with the <code>?</code> character. All query parameter values in peer DID URIs are base64url encoded without padding (consistent with JOSE conventions).</p>
	Other parameters MAY be used by a given implementation, so recipients of a peer DID URL should at least be prepared to parse the DID into its base DID value and its did parameters. All query parameter values in peer DID URLs MUST be base64url encoded without padding (consistent with JOSE conventions).</p>

	DID URI. All implementations of peer DIDs are required to recognize the meaning of this
	DID URL. All implementations of peer DID implementations MUST recognize the meaning of this

	process it. The parameter value can be extracted from a peer DID URI with the following
	process it. The parameter value can be extracted from a peer DID URL with the following

Add support for initial-state #23

Add support for initial-state #23

Conversation

dhh1128 commented Aug 29, 2020

dhh1128 commented Aug 29, 2020

kdenhartog Aug 31, 2020 • edited Loading

Choose a reason for hiding this comment

dhh1128 Aug 31, 2020

Choose a reason for hiding this comment

dhh1128 Aug 31, 2020

Choose a reason for hiding this comment

kdenhartog Sep 7, 2020

Choose a reason for hiding this comment

kdenhartog Aug 31, 2020

Choose a reason for hiding this comment

dhh1128 Aug 31, 2020 • edited Loading

Choose a reason for hiding this comment

OR13 commented Aug 31, 2020

dhh1128 commented Aug 31, 2020

dhh1128 commented Aug 31, 2020

OR13 left a comment

Choose a reason for hiding this comment

Moopli commented Dec 21, 2021

dhh1128 commented Dec 21, 2021

kdenhartog Dec 21, 2021 • edited Loading

Choose a reason for hiding this comment

kdenhartog Dec 21, 2021

Choose a reason for hiding this comment

kdenhartog Dec 21, 2021 • edited Loading

Choose a reason for hiding this comment

kdenhartog Dec 21, 2021

Choose a reason for hiding this comment

kdenhartog left a comment

Choose a reason for hiding this comment

Moopli commented Mar 29, 2022

dhh1128 commented Mar 30, 2022

peacekeeper commented Mar 30, 2022

dhh1128 commented Mar 30, 2022

dhh1128 commented Jul 17, 2023

kdenhartog Aug 31, 2020 •

edited

Loading

dhh1128 Aug 31, 2020 •

edited

Loading

kdenhartog Dec 21, 2021 •

edited

Loading

kdenhartog Dec 21, 2021 •

edited

Loading