Meeting minutes
ottomorac: today we'll be looking at a few PRs
… we'll also look at POST method use
… and dereferencing
… there's another issue around handling relativeRef
… and there are some other issues if we have time
… anything need adding?
DID Resolution PR Processing
<ottomorac> Add NO_CACHE_DISALLOWED error #183
<ottomorac> Add direct links to did extensions #184
ottomorac: we have 2 new PRs from my side
… these are both fairly simple
… one is just a reference fix
<TallTed> is stuck in previous meeting running over...
ottomorac: both should be easy
Make https binding mandatory #182
<ottomorac> w3c/
ottomorac: on this one we have a couple of questions
… we have a requirement to implement some HTTPS binding
… at minimum
… but there are some questions
<ottomorac> Question 1- Is it a requirement on DID Methods or on DID resolvers?
<ottomorac> Question 2 - How do we implement the concept of the 2 conformance classes (libraries versus deployed did resolvers)
ottomorac: I have heard that the DID Resolution spec can only require things of the resolvers
… but as you can see in the conversation, others feel this could be a requirement on the methods
… Question 2 is how do we deal with 2 conformance classes
… I haven't seen that often
… Wip did point me to specs where that has been done in the past
… but I would appreciate some guidance
manu: for the 1st question
… I think it's firmly a DID Resolver requirement
… for DID Method requirements, it would have to be in DID Core
… we could try to do that in DID Resolution, but it would likely get missed
… and it feels strange to force that on DID Methods
<ivan> +1 to manu on method requirements should not be here
manu: I haven't read the conversation, though, but would love to hear more
… it feels like a DID Resolver requirement
… for Question 2: can we do 2 conformance classes, yes, we can
… this happens fairly often
… especially between document conformance and library conformance
… I think it's fine if we have 2 conformance classes in this case
… really, this may be around do we require HTTP binding
… so, the 2 classes may be about that?
… so maybe we say DID resolving libraries vs. DID resolving services
… doesn't have to be that language, but services would be the ones that have to support HTTP
… however, libraries could be all kinds of things
… so we may need to use more general language
… and then we could use service to imply HTTP protocol support
markus_sabadello: I think we're mostly aligned
… just a matter of language, probably
… I think the current sentence isn't very clear
… I interpreted it to read that if you did not have an HTTP binding you were not a conformant DID resolver
… but as Manu points out, libraries may not support HTTP/S
… and in the current language, that library would not be conformant
… what Manu just called libraries and services are currently local and remote resolvers
… so maybe with the current language we assign the HTTP binding to the remote resolvers only
… but there's variation...
… so I was a bit unsure of how to resolve it
… and then I wondered if each method would then need to have at least one remote resolver that supports HTTP
ottomorac: this has been discussed before
markus_sabadello: yes. especially whether or not we require HTTPS binding on methods
ottomorac: so, there is an additional question if this becomes a requirement within DID Core
<Zakim> JoeAndrieu, you wanted to suggest its a DID method requirement conceptually, but we can't fix that under this charter
ottomorac: so the connection to DID Methods becomes clearer
JoeAndrieu: conceptually, I do think this is a DID Method requirement
… I agree with markus_sabadello that requiring that a did:key resolver require HTTP access seems wonky
… so I feel like the 2 conformance classes feels good
… I do hesitate to call it local
… but perhaps we can define it without defining it
… by focusing the HTTP requirement on the "remote resolver" only
JoeAndrieu: if we do this right, we won't be accidently requiring HTTP access to DLLs or similar
<manu> +1 to what Joe said.
<bigbluehat> +1 agreed
ottomorac: I'll resolve this using local and remote resolver language
… not sure if we need to define conformance classes here, but I'll handle that offline
HTTP POST method binding w3c/did-resolution#161
ottomorac: moving on to the next topic which is related in some sense.
<ottomorac> w3c/
<ottomorac> Currently, DID Resolution is specified with GET only. Many suggested a wording of “"you MUST implement either POST or GET.", however that would impact the testing suite.
ottomorac: so far we have said POST or GET
… but Wip raised some complexity concerns around the test suite
manu: I thought where we got to was mandating GET
… and you MAY implement POST
… which would be largely for corner cases
… so for 90%+ of cases GET is sufficient and we think for the remaining use cases POST can be used
markus_sabadello: I missed that previous call
… but that approach sounds right
ottomorac: who wants to handle this PR?
… k...I'll take it
… it seems innocent enough
Define how DID Methods can specify paths and their dereferencing rules w3c/did-resolution#156
<ottomorac> w3c/
<ottomorac> We discussed scheduling a Special topic call for issue #156:Define how DID Methods can specify paths and their dereferencing rules. Potential options includeL 24-Sept or 3-Oct. Thoughts from Joe and Manu?
ottomorac: I wanted to mainly get thoughts from JoeAndrieu and manu
manu: either of those dates works just fine
JoeAndrieu: <finds problems with day/date alignment>
JoeAndrieu: any of these can be made to work
ottomorac: let's go with September 24th then
… sooner is better
Create syntactic sugar for relativeRef feature w3c/did-resolution#181
<ottomorac> w3c/
<ottomorac> Suggestion from Manu on how we can remove the usage of relativeRef and introduce a change in the syntax so that these relative references can be embedded more directly into in the did URL.
<ottomorac> Moving from things: like did:example:123?service=agent&relativeRef=/images/123.png
<ottomorac> To: did:example:123:/images/123.png
<ottomorac> Notice the :/
<ottomorac> There is then a discussion between Dave Longley and Manu on the matter.
JoeAndrieu: this really ends up being part of the special topic call
ottomorac: so just bundle it into the call on the 24th
JoeAndrieu: yes.
markus_sabadello: I think this looks nice
… but is this conformant with the ABNF
… I think `service` and `relativeRef`, though, would still not go away
… and get combined with other things
… so I think this would be in addition too, not a replacement, correct?
manu: yes, this would be in addition
… the way we do paths now is with colons which feels weird to many people
… it may not be compliant
… we're trying to solve one of the long standing issues we've had is doing path stuff with DIDs is really awkward
… this is really just syntactic sugar for `relativeRef`
… we'll have to think of a way to make this work if it does have issues with the current spec
… there are ways we could handle it
<Zakim> JoeAndrieu, you wanted to say this would break some current approaches
manu: but what I hope we end up with a way to do nice looking path stuff that doesn't break compatibility with other systems
JoeAndrieu: unfortunately, this does break current syntax
… did:cosmos for one would likely choke on this
… I think the syntax sugar heads us the wrong way
… because we loose out on the need for it to be URL encoded
manu: I don't think it breaks the use of the colon
… the intent is not to break that specifically
… for URL encoding, we'll have to look at that more
… did:cosmos could say it doesn't support this syntactic sugar
dmitriz: I agree with manu and I think the syntactic sugar is extremely important
… we have lots of need for relative references for many use cases
… and `relativeRef` as the only option makes for very ugly URLs
… and if we don't address it people will roll their own solutions
… so we might as well fix it
markus_sabadello: I'm not sure about allowing DID Methods to override this
… these things do not have to be fully supported by all DID Methods
… and the services don't care how you get the DID document
… and I worry about making this syntactic sugar method dependent
dmitriz: big +1. I think that's what at issue here
… how do we keep each DID Method from solving for `relativeRef` their own way
… one potential option is to define a service endpoint that defines the default relative ref service ID
… so, a 404 service of sorts
manu: dmitriz I interpreted what you said in two different ways
… my concern if we don't make it optional is that we'll get formal objections
… that's the only reason I'm proposing it be optional
… but I expect many would opt in
… but others may not because they chose a different path before this was introduced
… I don't want to make it a requirement and then cause problems for them
… and we don't want to make this painful for various methods if we can avoid it
dmitriz: this does get revisited by several did methods
… we need relative references
… the DID Core syntax is too unwieldy
… so, we need to find a did method where this is better
… or create our own did method
… and it would be better to have this solved in someway at did core
<dmitriz> did:example:123?service=agent&relativeRef=/images/123.png
<dmitriz> serviceEndpoints: [ { type: "default relativeRef service", value: agent } ]
<manu> oh, right, excellent, that makes sense to me.
dmitriz: these are some approaches
manu: I think that's an excellent point dmitriz
… that would also potentially address JoeAndrieu's concern about how did:cosmos does it now
… and looking for that service endpoint would be a way to know if/when it's available
… and situations like cosmos's would be more manageable through this expression
… and if they ever wanted to do this, they'd have a mechanism that doesn't break backwards compatibility
… another thing dlongley brought up was about static vs. dynamic references
… imagine if a service is constantly under attack and they're having to shift those around to stay up
… so, static resolution gives you a static URL and you dereference it staticly
… and a dynamic resolution would provide a protocol that would eventually give you a path
Wip: I think this is a great discussion, but I think we should move on and leave the rest for the special topic call
… the chairs also feel this is one of the last remaining things to address in the spec
<Zakim> JoeAndrieu, you wanted to say I think the colon mechanism is a non-starter from a charter standpoint
Wip: so I'd like to pause now, address it more on the 24th, and then make more time at TPAC
JoeAndrieu: delaying until the special topic call makes sens
<Zakim> manu, you wanted to say I don't agree :P
JoeAndrieu: if we go with the :/ approach, we'd have to change the ABNF
manu: that's the bit I was saying about language lawyering our way around it
… it's not a DID and it's not a DID URL...it's a thing that gets translated into a DID
… ideally, we don't have to...but that is an option
… we could use any other separator
… but this might be one of the features of this
… since it is not valid syntax, then no one could have picked this
… and so we know it won't break other things
JoeAndrieu: no, this change would break existing DIDs once this is introduced
Model accept as the HTTP accept header w3c/did-resolution#116
manu: so, we want to avoid that, so lets keep discussing
<ottomorac> w3c/
<ottomorac> There was agreement to model it after the HTTP Accept Header, there is change required in the DID resolution algorithm. We need someone to volunteer to create the PR.
ottomorac: looking for a volunteer for this PR
markus_sabadello: I can take this one
Address incompatible entries in extensions registry #150
<ottomorac> w3c/
<ottomorac> We had some prior discussion of how to address this between Joe and Manu. Will discussed maybe adding an issue on the DID Extensions registry.
Wip: we do need manu for that, and can happen on the special topic call
JoeAndrieu: agreed
… all these options need to coalesce
markus_sabadello: agreed. this can be in the special topic call
… in my mind, the examples that are here are quite different than the syntactic sugar scenarios
… and what we have here is completely did method dependent
… the differences can be discussed on the special topic call
ottomorac: would it make sense to add the folks from did:cheqd to the special topic call?
markus_sabadello: yes. I will do that
… they were some of the first to explore that
JoeAndrieu: just to clarify, we were in the registry before them ;)
… but it would be good to get someone from there to join the call
ottomorac: anyone else we need to add?
JoeAndrieu: yes. I will reach out to others
ottomorac: 10 Eastern on September 24th
ottomorac: any other pressing issues?
JoeAndrieu: yes. maybe pchampin can help us clarify
Other topics
JoeAndrieu: what do we do with non-members who would be good to have on this call?
… special topic call significant contributions can only be made by members
… could we invite them as an invited expert?
ottomorac: we did want to cap the number of invited experts at some point
Wip: we could do that, but we only really need him for that one call
ivan: you can time limit the invitation
… we don't usually do that
… but we could say it's only for 3 months, for example
JoeAndrieu: I'll reach out. If he can't join us, we can defer that discussion
… if he can make it, maybe it's worth the effort to invite him
ottomorac: k. that's it for today
… thanks everyone!