DID WG Special Topic Call on Link Relationships — Minutes

Date: 2020-08-18

See also the Agenda and the IRC Log


Present: Markus Sabadello, Drummond Reed, Manu Sporny, Dave Longley, Daniel Burnett, Orie Steele



Chair: Daniel Burnett

Scribe(s): Manu Sporny, Drummond Reed


1. Link Relationships

Manu Sporny: I can kick us off

Orie Steele: One of the handful of issues related: https://github.com/w3c/did-core/issues/368

Manu Sporny: I have a few proposals, emoting them in IRC.

Daniel Buchner: 368 should be relatively simple

Drummond Reed: Could you talk about preferredId?

Daniel Buchner: Canonical form of an ID… that’s what it’s supposed to mean.

Manu Sporny: His idea was to see if there was an uncontroversial one to start with

Drummond Reed: How do we want to start?

Manu Sporny: Easiest first?

Orie Steele: Can we guess at which one might be uncontroversial?
… That there are four proposals, might be potentially better to define link relation types in some formats first. Do we rely on link rel types based on this group or other groups?
… We may want to define link relation types generally, then I propose as first, sameAs is the one we discuss first.

Drummond Reed: I think we do have to talk about all of this - do agree of general idea of establishing an overall approach for link relationships – that does take us down into underlying questions. Reusing link relationships established elsewhere, unfortunately, sameAs might be one of the hardest.
… open to discussing that first… tend to agree w/ Dave, alsoKnownAs might be easiest to tackle.

Daniel Buchner: The easiest ones will likely be the ones where the method determines them, not the user

Markus Sabadello: Some of these are properties or relations that exist elsewhere such as owl:sameAs, others are things we might invent… canonical/preferredId - discussion on whether existing link rel called canonical could be reused there.

Daniel Buchner: AKA: ones that are deterministic and explicit vs something that is mutable

Drummond Reed: +1 to canonicalID

Daniel Buchner: Easiest ones are not subjective relationships… canonical is not subjective, what we want canonical to mean, method has two identifiers that are one and the same, the method is saying that one is canonical. Dragons be where user’s specify things… vs. methods.

Orie Steele: dbuc is saying that the DID Method controls some… where the DID Controller controls others….

Drummond Reed: +1 to the subject being relationships as arcs in the graph

Manu Sporny: Are we talking about naming the arcs in a graph? I thought that’s what we were talking about, but perhaps other’s dont think so

Dave Longley: I think we’re talking about arcs in a graph… properties of the DID Subject, expressed in a DID Document, agree with that.
… In response to Daniel, tackling canonical first, it’s more definitive, but potential issue w/ canonical is, if there is a DID Method w/ canonical DID, you must choose X, you wouldn’t express that in a DID Document, but rather a rule in a DID Method.

Orie Steele: +1 to arcs in a graph… <did:example:123?blahhh> $MD_CODE$

Drummond Reed: One of the requirements of canonical ID in XDI is that you could only have one…
… if there was such a property, is there a restriction that you can have only one?

Markus Sabadello: To respond to manu, thought we are talking about arcs/nodes in a graph… different tech out there that deals w/ arcs/relations – Linked Data, Web Linking (link relationships)… that’s where canonical exists.
… Orie found a spec that explains how link relationships known from HTML, JSON-LD,… with that, if we want this sort of functionality, we can reuse this canonical property w/o inventing something new.

Orie Steele: +1 to not inventing new things!

Markus Sabadello: Other thing about DID Methods, some DID Methods already have this functionality, others leave this up to DID controller, see this w/ other features, we shouldn’t make too many assumptions on when/how

Daniel Buchner: Simple use case – long form of DID base64 of initial state, short form is hash of that. For most decentralized systems, there are 10s of seconds of delay vs. when you commit… usually minutes.
… You might not want to use something that’s a KB long, once you resolve long form, can’t put that in ID right now, URL parameter, so you put long form in ID, once it’s anchored, you can use short form.
… Use this one instead, long form when it’s unanchored, short form when it’s anchored.

Dave Longley: I still don’t fully understand the use case… do you not have the short form until it’s anchored? Maybe you need another property to say longer form? But that might also indicate it’s a metadata property of DID Document.

Daniel Buchner: Create DID > no one can resolve the short form for 10 minutes > use the long-form while short is not resolvable > when it is published, propagated, and resolvable, put the canonical short-form in so it is now used by everyone who resolves the doc

Dave Longley: dbuc: but it doesn’t matter if you can’t resolve it, that’s the id

Dave Longley: dbuc, it sounds like you should put the short form in the id always, no matter what – and say, externally, that you resolved the DID doc by using the longform.

Drummond Reed: To manu’s point, if it’s the same approach as canonical ID in XDI - it is basically a label on an arc that explains that it’s an arc back to the same node, and identifier to the same node.

Orie Steele: here is another example of this… https://github.com/decentralized-identity/did-spec-extensions/blob/master/parameters/signed-ietf-json-patch.md when your URI contains params that do mutation, you might want to refer to the non mutated resource

Drummond Reed: I do see it clearly - form of link relation, arc value of another arc.
… Second thing, what Daniel just described wrt. sidetree is an example of abstract methods, multiple instances, but same method… I don’t think they’re planning on sharing same namespace.

Daniel Buchner: KERI would be the same thing if they did this.. if you created a DID, it’s not propagated, you know long and short form immediately… if you gave short form, not propagated, have no record of this, you have to use a long-form self-resolving DID … implementation looks at it, not anchored, use long form, transform data into doc, hand it back to you.
… Until it’s anchored, use canonical short form in DID Doc, while in transit, use long form self resolving version. as soon as anchored, put bitly link in there, when you get DID Document back, sign over canonical one. Don’t sign over long form, use short form.

Orie Steele: canonical solved the problem of <did:example:123/pathname/foobar?query1=1&query2=2> canonical <did:example:123/path/foo?query1=1&query2=2> …. its used by search engines to deduplicate links in html…

Dave Longley: I think it’s fine to have long and short form, long is DID URL and say long form needed until it’s anchored, long form or short form, ID should be short form.

Daniel Buchner: can’t put the long for in the id prop

Daniel Buchner: meaning there will be many failures

Daniel Buchner: Resolving parties will just take the short portion and kill resolvability

Dave Longley: you don’t need canonical form… resolver that understands the concept, short form in ID … if anchored, go out to ledger and grab version from ledger. Check ledger first if not there then choose long form, regardless, output should have ID, if you use long form, it helps you resolve things that are not on ledger yet.

Markus Sabadello: I don’t think these properties are metadata, they’re data about the subject.

Daniel Buchner: If you are a resolving party and you take in a URL, then drop the parameters, you are boned

Manu Sporny: Daniel’s use case doesn’t make sense to me.
… if you have a long-form of a DID, and if you have that, the short form is deterministic
… if your system needs to store the short form, you can continue to use the long form until the short form resolves

Daniel Buchner: There’s clearly a disconnect here

Manu Sporny: so it sounds like having a separate canonicalID property is the wrong solution
… why can’t a system just keep the long form around until the short form resolves

Drummond Reed: So what I heard Daniel saying is that both the long form and the short form need to be resolvable

Daniel Buchner: The issue is if I hand you the long form – ABNF says I can’t use URL, I had you a long form, it may never be anchored, you don’t know if it’ll never be anchored, DID Doc comes back w/ short form, don’t use short form, it’s not going to be anchored, you have to remember to use long form that has parameter, store that as ID and then do startswith queries on database, you have to use long form, short form is not going to resolve… creating big minefield, if you propagate both, we’re in method specific land.
… You can’t look up short form to look up, you have to use long form…

Drummond Reed: If this use case was handled same was as also known as, alternative DID, one or more - don’t think it’s as controversial, here’s a method that has a reason to have also known as… no semantics to being canonical.

Daniel Buchner: It’s like alsoKnownAs, but just one, and you SHOULD use it

Daniel Buchner: If you don’t want to use it, you don’t have to

Daniel Buchner: there’s no mandate here

Orie Steele: We’re not here to tell people how to build their DID Methods, we need to specify relationship arcs – should we say you can use these particular labels… goal here is not to tell people to use particular DID Methods, define terminology and vocabulary that come with rigorous semantic definitions.

Daniel Buchner: https://tools.ietf.org/html/rfc6596

Orie Steele: Don’t want to use canonical, don’t use that, DID Method implementers are responsible for applying terminology, you can use them or not.

Dave Longley: +1 to Orie, but this sounds like an interop problem

Drummond Reed: +1 to Orie’s point

Manu Sporny: I am not saying that Daniel or Sidetree should do a certain thing, but that the use case doesn’t make sense
… I’m trying to drive towards a concrete use case and thus a definition of what that link relationship is going to do

Orie Steele: here is the use case: “ This specification defines a model for the relationships between resources on the Web (“links”) and the type of those relationships (“link relation types”).”

Manu Sporny: if we don’t have definitions, then these discussions never end

Orie Steele: https://tools.ietf.org/html/rfc8288

Orie Steele: manu https://tools.ietf.org/html/rfc8288#section-2

Drummond Reed: Agree with except the last thing you said - can connect offline, there are other use cases.

Daniel Buchner: I can’t put a DID + URL param in the id prop

Drummond Reed: Generally, do like the idea, try to incorporate existing link relations that are defined, do think that’s a good idea… if those are clearly defined, we may have use cases that have particular link relation. If DIDs are going to represent anything w/ identity, I can almost guarantee link relations are going to come into play.

Daniel Buchner: The canonical property would be: There is a canonical form of the identifier in the id property that you should use.

Orie Steele: the did spec forbids did params in the id field.

Daniel Buchner: I cannot put a DID property in the DID property… if they see short form in the ID, they may attempt to use the short form.
… I want to be able to hand you a firstly generated ID at time of generation to resolving party to forever more be able to use it, auto-upgrade when people use that DID… then there is a canonical property and they use it.

Dave Longley: it seems that for that did method you just have to keep that did URL around until you can upgrade … and the id is just the short form.

Drummond Reed: I’d like to touch on ones that Manu proposed
alsoKnownAs, it is an alternative DID, there is a PR already for that one.

Manu Sporny: Let’s see if we can do alsoKnownAs

Drummond Reed: PR for alsoKnownAs property: https://github.com/w3c/did-core/pull/355

Dave Longley: alsoKnownAs seems ok to me, only question is why restrict it to just DIDs? Maybe another kind of ID… maybe restricting it is for PII reasons, maybe for VDR that DID Document is a part of. Maybe you want to say one DID is also known as another DID.

Drummond Reed: I agree with Dave, public use cases and private use cases, in DID Documents… can be shared either way - it is just something that standardizes semantics…
… I don’t want to mention the HTTP Range issue that shall not be named (scribe note: that would be 14 :P)… we could say this is for DIDs and not other forms of URIs.

Daniel Buchner: I literally don’t have another option to do this - because the alternative is doing some non-standard out-of-band assumptive coding on the part of resolving parties, so I guess we’ll just code against a non-standard prop and go for it

Drummond Reed: practical argument about that – we could decide no reason to distinguish, could do any URI

Daniel Buchner: I really think if folks were working with purely decentralized systems that had longer propagation times, you would instantly realize the issue

Daniel Buchner: relativistic issues tend to only be an issue when you have a system that has to actually deal with relativistic issues of time linearization

Orie Steele: I think my issues around alsoKnownAs is decision to create brand new identifier, type restriction specific to DIDs, address link relations to that specific context. Not starting with vocabulary elsewhere, would object to it knowing that there was never going to be sameAs other more accurate and completely described vocabulary that’s an alternative.
… If we are saying there are going to be many of these, definition means that people will use other things.

Dave Longley: In terms of data model, the value of this thing is a URL, which covers DIDs, we could have DID methods that place further restrictions, don’t need to restrict.

Manu Sporny: wants to put forward a straw poll

Orie Steele: i think i agree with dave, feels like its just poorly named sameAs :)

Proposed resolution: Add the alsoKnownAs property to the DID Core specification which expresses a uni-directional alias relationship between the DID Subject and another DID Subject. (Manu Sporny)

Drummond Reed: +1

Orie Steele: +1

Manu Sporny: +1

Dave Longley: -0 would prefer it to allow any URL and fix the language a bit

Daniel Buchner: I am too salty to respond

Orie Steele: oh cool, since they are different, we can register both, and define the difference to avoid confusion :)

Markus Sabadello: +1 if it works for all URLs (not only DIDs)

Dave Longley: +1 if we’re not limiting to only DIDs and we’re talking about referring to the same entity with different identifiers

Daniel Buchner: It’s not a vanity DID thing

Drummond Reed: It could be registered in DID Spec registries.

Daniel Buchner: it’s a functional show-stopper

Drummond Reed: willing to work with you offline, understand your use case, more general use cases for canonical ID.

Dave Longley: dbuc, i think addressing issues with decentralized ledgers that take a while to resolve/anchor things is important – i’m concerned about the proposed solutions.

Drummond Reed: This has come out in discussion about appendix issue, are we going to tackle HTTP Range 14 or treat… any reason to distinguish between information resource and non-information resource… they can and can’t have representations… then things get a fair amount simpler.
… we can probably come up with some answer that we can deal with… whole call on link relations.. I need answer to that to move forward with A appendices… b with representation property.
… If we make this decision, we don’t need representation property

Proposed resolution: Add the alsoKnownAs property to the DID Core specification which expresses a uni-directional alias relationship between the DID Subject and any other URI. (Manu Sporny)

Drummond Reed: +1

Manu Sporny: +1

Orie Steele: +1

Markus Sabadello: +1

Dave Longley: +1

Daniel Buchner: 0 - won’t say no to something I don’t care about, because it’s optional anyway

Resolution #1: Add the alsoKnownAs property to the DID Core specification which expresses a uni-directional alias relationship between the DID Subject and any other URI.

Daniel Buchner: you can add bananaOctopus for all I care, as long as it’s optional

Drummond Reed: of the four properties, representation only exists because of one view…

Proposed resolution: Add the representation property to the DID Core specification which expresses a relationship between the DID Subject and a URI-based resource with associated MIME Type that is a representation of the DID Subject. (Manu Sporny)

Manu Sporny: -1

Daniel Buchner: I don’t really know about this prop, so I will just abstain

Drummond Reed: 0

Orie Steele: -1

Dave Longley: 0

Markus Sabadello: 0

Manu Sporny: Special topic call could be how we justify that.

Drummond Reed: Or, what stance we take on Cool URI, even if we publish a NOTE that doesn’t directly affect the spec.

Daniel Burnett: We’re done.

2. Resolutions