need rationale in spec for fully qualified DID references as the value of "id" fields about did-core HOT 19 CLOSED

@csuwildcat is assigned to this issue.

from did-core.

Based on the discussion from the previous CCG thread, I would move to allow fragment-only ID values for all DID method types, and don't see why something like did:web would change that. DIDs that are based on something like did:web should be fundamentally different DIDs, so I don't think the argument holds that they create some special case.

from did-core.

I think it's simpler for interop if all IDs use absolute URIs post resolution. This does not mean that, internally, DID methods cannot store DID Documents however they'd like. But when an application uses a resolver to get a DID Document, I think, ideally, the IDs would all be resolved. If there's agreement with this from the group, then we'll have to figure out how to say this in the spec since it's a data model only spec -- it may ultimately need to be a constraint in a future resolution spec instead.

from did-core.

I am a lot more comfortable with @dlongley 's suggestion (absolute values after resolution) than I am with the convention proposed earlier in the comment thread (absolute values before resolution). I could probably get behind post-resolution absolutism :-), although I need to ponder a bit to be sure.

Note, however, that this changes the duties of a resolver in a non-trivial way (essentially, rewriting DID doc content) that we would need to carefully specify in the DID resolution work. @peacekeeper Note as well that proofs of DID document integrity/correctness may break if content is rewritten in this way, depending on whether the holder of a resolved DID possesses all the input state against which the resolved doc must be compared.

from did-core.

from did-core.

Why is disallowing fragment-only simpler?

If IDs can be treated as opaque by consuming applications then they do not need to understand yet another layer. This complication can be left to the resolution layer -- the application doesn't have to care.

from did-core.

from did-core.

By application, do you mean some app/service that gets the DID Doc and
needs to select/use ID'd elements within it? If so, the function they run
is trivially different to parse URI + fragment or fragment-only.

Those applications don't necessarily need to run any function to parse the URI. They can treat it as opaque. By definition, this is simpler.

from did-core.

I think my slight preference would be to allow both (relative DID URIs and absolute DID URIs). An application would then have to understand both, just like a web browser understands both relative and absolute URLs in an HTML document. A DID Resolver could support an input option to request transformation of such URIs (see w3c/did-resolution#40).

But I agree this makes processing more complicated (at least for non-RDF/JSON-LD processors), so I'd also be fine with always requiring absolute DID URIs (or always requiring relative DID URIs).

from did-core.

I think my slight preference would be to allow both (relative DID URIs and absolute DID URIs).

Remember that allowing both means that some sort of canonicalization (not only for documents, but URIs as well) is required before digitally signing the byte stream. Extra complexity. @dlongley, @dmitrizagidulin have we considered this for use cases like did:web, where there may be a proof and the signature is over a set of relative or absolute URLs? My gut tells me that it's not an issue because what's signed is signed and you can verify and transform the signed output however you'd like. Need to understand if there are attacks where you can set BASE in did:web and clone/move the document and do something nasty.

from did-core.

Here's another question: For service endpoints or public keys that have absolute URIs, should there be a requirement that the authority component of those URIs must be the same DID that was resolved (= the base URI)? E.g. if the DID is did:m1:123, would it be invalid to have did:m1:456#key-1 in its DID document?

If yes: The application can't treat the URIs as opaque then and has to understand an additional layer. Or a resolver would throw an error for invalid URIs.

If no: Wouldn't this introduce all sorts of attack vectors?

from did-core.

What was the resolution here? I was still hoping to use relative references in fragment IDs so that we don't have to add the DID everywhere in all those strings. Is this supported, or not? the assumption of the fragment being relative to the DID/DDO it resides in is not a leap, imo.

from did-core.

I second @csuwildcat proposal to use fragments. There are many DID methods that do not know the value of the DID method-specific identifier until after the initial DID is created, which means the DID method is responsible for filling in the actual fully qualified DID when resolving the DID Document. Currently, only the top-level id element needs to be filled in.

Furthermore, for methods that store the actual DID Documents, having these ids be URIs results in unnecessary DID Document storage bloat.

from did-core.

See: decentralized-identity/sidetree#368

I'm strongly against the use of pure fragments , I believe id should remain a URI.

I am in favor of being even stricter about its structure, using a regex.

DID Method Resolution can ensure this property, its a mistake to allow for variance here, it can only make things worse.

from did-core.

I am in favor of Daniel B and Chris B's fragment support, and strongly opposed to Dave L/Orie's request to require that the value be fully qualified. All of Chris B's arguments apply in spades to the peer DID method; using fully qualified id properties would be onerous and make the method needlessly clumsy.

I'm strongly against the use of pure fragments , I believe id should remain a URI.

In HTML land, pure fragments are URIs--relative rather than absolute, but nonetheless URIs. This ticket is about deciding whether to consider fragments to be URIs in DID Doc land as well. We get to decide what URI means in DID Doc land. So saying "#fragment" is unacceptable because "id should remain a URI" is a circular argument that begs the question.

See [sidetree ticket]

The arguments made in this ticket assume that the data model for DID docs should be JSON-LD. We are having a separate conversation about the advisability of that assumption. I would like to separate the two issues. What arguments in favor of requiring fully qualified id properties can be made without assuming JSON-LD processing?

from did-core.

its a mistake to allow for variance here, it can only make things worse.

Yeah, agreed, also this:

Here's why we can't have nice things... :) (this is somewhat tongue in cheek)

Even if we were able to say they MUST be fully qualified URIs, some developer somewhere will commit a fragid-only DID to a ledger, and then your software will fail because clearly their DID Document is broken... they'll complain and bring all their friends with pitchforks to your github repo and threaten to not use your software unless you fix the bug... you'll insist that it's not a bug and it's not your fault that they did the wrong thing... and then some other DID library implementer will come along and support relative fragids in their software, which will do the proper transformation, and then people will move away from your software to this other software that does the thing that the developers want, which will break the entire ecosystem until everyone supports relative fragids and we update the spec 10 years later to finally admit that relative fragids SHOULD NOT be used, but software won't break if they are. We can't have nice things because people just want to use relative fragids and will do so even if it's wrong. That is, unless we can convince all of these communities to not add unnecessary complexity to libraries - happy to skip merrily into that conversation with you, it's happened in so many WGs and it almost always results in relative fragids because 1) people don't understand layering, and 2) it eats up precious WG time when there are other higher priority things, and 3) eventually someone throws a chair at someone and puts out an eye (usually yours, even though you're making a valid point).

I suggest we work with DID resolvers and library authors so that any relative fragids are automatically resolved to their fully qualified form. That enables us to say that a valid DID Document MUST contain fully qualified URIs for all ids and it's up to implementers if they want to use fragid only things in intermediate DID documents. We might have to add something to the DID Core spec to specify the concept of a base URL and how relative URLs are resolved in a DID Document and say you SHOULD NOT use relative URLs, but if you do, resolve them against the BASE_URL (which is the DID).

from did-core.

Yes, I agree this is 100% a circular argument :)

I'm speaking mostly from the perspective of existing software (such as the universal resolver), not working with non URI based id values...

Since @msporny has beat me to comment, I'll just restate my preferences:

1. Sidetree based DID Documents returned from the Method Resolver are valid JSON-LD (no transformation required).
2. DID Core spec has documented a safe transformation process that resolver / library implementers can use, for relative URIs.

from did-core.

There is now a concrete proposal that attempts to address all of the points made in this issue thread (and the previous CCG issue thread) in a separate PR:
#201

I'm going to close this issue and folks can continue the discussion in #201, which contains a concrete suggestion and will have a PR soon.

Object if you don't agree on closing this issue and pursuing a concrete PR in #201. If there are no objections, this issue will be closed.

from did-core.

No objections have been raised. Closing.

from did-core.