Meeting minutes
Debrief Special Topic Call for DID Resolution Test Suite on 6-Aug
<ottomorac> w3c/
Wip: Yes the special topic call went well, Ben and Parth will be setting up the infrastructure, the plan is to keep meeting every 2 weeks on Wednesdays during the special topic call...
Wip: Starting with tests are going to check the correctness of did resolution... we expect the tests to be generic...
Wip: Also we decided that for these calls since they will be technical in nature and part of the objectives was to have knowledge transfer from DigitalBazaar team to the rest of the team....
Wip: Then we will use the infra from the CCG meaning the Google Meet and Transcription
manu: the only thing I need to do is to create a meeting in the CCG infra account for this
… Then include the chairs as people that can convene that meeting, and configure the minutes generation to trigger
… Then it will be setup automatically and will run automatically as well as sending the minutes out to the ccg
Wip: Sounds good. Please just provide me with the link and the details so that I can update our regular agenda....
Manu: Yes will do that...
manu: To send the minutes out to the DID Wg, it might be a bit more tricky to post to the mailing list
… it is possible, but a bit more work
manu: This is possible
pchampin: The infra is currently sending emails to the CG mailing list. Dont see why this would be different for the working group mailing list
manu: Yea but you can't post unless you are a member to catch spam etc
pchampin: I may need to allow the first email to go through. This is possible
<Zakim> Wip, you wanted to suggest we can just manually reference it in the meeting for the special topic call
manu: Anyone can also forward it. Not concerned about it
Horizontal Review Update
manu: There is no update on the horizontal review from my side
… this is typical
Wip: Yes we have this on the Agenda just as a reminder... I am bit unclear as to how the break down of the work is. Perhaps Markus can clarify the scope of the work
markus_sabadello: I dont remember can someone remind
manu: Last time we discussed this, the TAG had changed the process meaning we dont require an explainer anymore
… Instead we can request a horizontal review from the TAG and point to the parts of the spec that answers these questions
… if we dont have those sections yet in the spec, then we need to write them
… That would be it. It should be a lighter lift
… Someone needs to look at the list and map it to the section and raise new issues against the spec where they are missing
Wip: Yes I will create an issue after this call with the work that Manu just described that needs to be done. Also the other item is the Privacy review....
manu: Yep, that is exactly right. Someone needs to go through the questionaire and try to answer the questions
… The privacy questionaire should be completable without issue
… You typically want to start with the TAG review
… Other reviews ask about the TAG answers
markus_sabadello: we should create two issues one for the TAG and one for the PING review, then we can link the the relevant questionairre
ottomorac: I thought we already had an issue for this open
Wip: No this is for accessibility and internationalization
<manu> Suggestion is to follow this general issue template for the horizontal reviews: w3c/
manu: We have three issues, one horizontal review and two specific self reviews
… markus_sabadello for the links I am linking to DID core issue #885, this shows you how the answers look like
… We just need people to actively work on these to move them forward
<Zakim> JoeAndrieu, you wanted to ask about security review changes
JoeAndrieu: I just wanted to raise that the security review may be asking for something different than what we have prepared in the past
… Simone's goal is to establish threat modelling as the way we write up security review
… I don't think this is ready yet, but it might be coming down the pipe
Is percent encoding the fragment (#) really conformant with the URI RFC? w3c/did#898
ottomorac: moving on
This is related to example 6 in the DID core spec, link: https://
There is discussion by Markus and Dave Longley about the steps that could be taken to de-reference the example that is provided in the spec and how to handle percent encoded fragments.
markus_sabadello: I think from a URI syntax perspective, both are valid
… A fragment in the URI is okay, and so is an encoded fragement
… in this specific case, this is about example 6 in the specification. In the section about the DID fragment. This is a URI fragment, not encoded
… I think a change needs to be made here in example 6. To have a fragment not an encoded fragment
… This has changed, from 1.0 to 1.1. I think this was a mistake, we should change it b ack
manu: looking at the example now ...
I did read the thread, markus_sabadello is right. There are two different interpretations of the URL
… I am a bit concerned about moving it back
… In example 6, I will paste in
… This is not clear to me if the fragment identifier in this example is meant to talk as a fragment in the final document. As this is relativeRef
… Example 6, the fragment identifier is pointing to something other than a DID document. As a result, I think it does need to be percent encoded
… However, I see that this is confusing in this section
… We need to figure out what this means from a did resolution section
… I dont want to put this back
… If we put this back, then it is a pointer to the DID document
<manu> Here's the direct link: https://
<manu> specific text we're talking about: did:example:123?service=agent&relativeRef=/credentials%23degree
<markus_sabadello> Previously it was: did:example:123?service=agent&relativeRef=/credentials#degree
<JoeAndrieu> @manu can you put the two options in chat? I don't know what you mean when you say "put it back"
manu: If you put a fragment identifier on that DID URL in exampl6. then that fragment is pointing to the DID document
… One problem is there are two interpretations of this example
… It is not clear about what should happen in this case
… It depends on how you are going to process this thing
… Different impls will do different things
markus_sabadello: What makes this complex is exactly the use of the relativeRef here
… Dave and I made comments to this effect
… If it is percent encoded, then the fragment is part of the relative ref value. If it is not precent encoded, then it is part of the DID document
… Both variations might even dereference to the same thing
… However, the dereferencing algorithm is different
… First we dereference the DID Url with the service and relativeRef parameter. Then we dereference the fragment on the result
<Zakim> JoeAndrieu, you wanted to say I think it is actually clear. not percent encoded means it is NOT part of the relative ref property
markus_sabadello: If we percent encode, then it is part of the relativeRef value. I still think this is the same result. But handled differently. The difference is that the percent encoded fragment is not a DID fragment
JoeAndrieu: I endorse markus_sabadello here. I think we need to move it. Because this section is about the DID fragment
… There is an option to say you can do either. And one interpretation is that these are equivalent
… The intention of this example is that that fragment is part of the relativeRef URL
… Modelling this that the relativeRef property includes the DID fragment is what we should encourage
… This is the clear way that you specify that the fragment is into the doc that is relativeRef. Not the DID document
manu: plus one to what JoeAndrieu said. ANd agree with markus_sabadello. We need to move this out of this section
… I think this is legitimate. I just don't know how other developers would interpret this
… Concerned about misimplementations and corner cases here
… Esp with regards to WHATWG
… I think markus_sabadello interpretation is correct per RFC3986. But might not be in regards to the WHATWG
… We would need to test against other systems to confirm what markus_sabadello has said
… Agree with Joe's second point. If we allow both we will have to explain it in depth. And people will still get it wrong.
… If you are going to do this relativeRef stuf, and include a fragement to the referenced resource. Then that frag should be encoded in the realtiveRef.
… The only downside, is that the URLs that we would like to be nice URLs end up with some ugly syntax
… +1 lets move it out of this section at a bare minumum
… second, lets add a section that walks through all that we have just discussed
… three, we might want a section that documents that these are semantically equivalent. But we would have to check with WHATWG to see if this is actually the case
markus_sabadello: If we say that the fragment has to be percent encodedf to be part of the relativeRef value
… It raises the question if real DID fragments are allowed on this relativeRef
… In regards to what is deployed on the web today. I agree this is useful to check
… In my mind, these things behave similar to http. E.g. 302 redirect. If you dereference a http url with a fragment and a server redirects you to another URL, then the original fragment is preserved
… That is what I am trying to accomplish here
… We can look at this closer
<Zakim> JoeAndrieu, you wanted to say I think they are allowed. just not recommended
JoeAndrieu: I think I am aligned with markus_sabadello
… I think we can't actually prevent people from saying this is a DID URL and I am going to put a fragment on it
… This is going to parse, but it may not parse in all parssers
… We want to encourage the use where this is clear
… This can get confusing. It is about communicating this and providing an easy route
<Zakim> manu, you wanted to note "fragment semantics"
manu: Adding more complexity to this...
<TallTed> Servers never see fragment IDs that follow unencoded `#`. Servers only see fragment IDs that follow `%23`.
manu: every media type can define their own fragment semantics
<manu> https://
manu: e.g. this is the text plain fragment semantics
… This is to say that application/did can define our own semantics for fragments
… This can be a foot gun
… people expect fragments to work like http urls
… I agree we cant stop people from doing this
… But we can nudge people
… bigbluehat added a great example`credentials#degree#in-the-did/did:example:123?service=agent&relativeRef=/credentials%23degree#in-the-did/credentials#degree#in-the-did`
… The relativeRef is what makes this complicated
… We probably need a section that talks specifically about fragment semantics
… Specifically highlighting the equivalence that markus_sabadello has mentioned
… I think we can say semantically, the interpretation of a percent encoded fragment and a DID fragment point to the same thing
bigbluehat
<TallTed> bigbluehat -- that s/ is going to fail because too many / in it
bigbluehat: in a URI you only get one hash symbol
… To sum it up, percent encoding properly sets the value of relativeRef to the whole value
… The URL parsing stuff is literally just breaking the string at the first hash value. Everything to the right goes in the search params
… Such that if you stick a hash anywher, anything to the right is the fragment identifier
… If you want the value of relativeRef= some value. You must percent encode that, otherwise you are not going to pass that into the response of the relativeRef
… The parsing will assume it is part of the DID document otherwise
… This is true in URLs too
<ottomorac> +1 to what Ted is saying
We should do progressive examples
TallTed: part of the difficulty is that too many pieces are made part of the URL string. Ideally we start with the simple case and add complexity one bit at a time
… This is complex. Most people dont understand this. Some percentEncode. Others dont. People make mistakes
… Even experts get this wrong
… We should not have this ultra complex example early in the doc
… Two complex discussions at once. If not three
… relativeRef, fragments and fragment encoding
… Clients should never send anything beyond that first hash to the server
… A server that receives a string with an unencoded hash, should chop it off
… many impls get this wrong
ottomorac: To summarise, lets separate the examples out
<Zakim> manu, you wanted to note that we're talking about DID URL fragments, not DID fragments... and for DID URL fragments, there are two passes on resolution, IIRC. and to note we don't define relativeRef :)
manu: again, reading the spec. We dont define relativeRef at all. We just assume this is defined elsewhere
… Unless we define what relative ref is an how it works
… Maybe this example and the discussion of it needs to move to did resolution
manu: what you were talking to bigbluehat presumes a single pass over the URL. Wheras I think this might be a two pass process
… First pass will parse the URL and pull stuff out. Then it will construct a new URL using relativeRef
… I think that is what markus_sabadello was speaking to
… There are many interpretations, and its complex. WOndering where this belongs. Dont want to confuse people more than we need to
zakim close queue
bigbluehat: I propose some action steps. DID core defines relativeRef pretty well. It says you should percent encode
… I think example 6 needs to be changed.
… The value of relativeRef is refernced as coming from 3986
<JoeAndrieu> https://
bigbluehat: I would add a different example. We need some different examples
… The difference here is that we don't have a server exchange happening here. There are two steps going on, not sure if we are distringuising clearly
markus_sabadello: manu is correct that we dont define how to process relativeRef much
<JoeAndrieu> relativeRef A relative URI reference according to RFC3986 Section 4.2 that identifies a resource at a service endpoint, which is selected from a DID document by using the service parameter. If present, the associated value MUST be an ASCII string and MUST use percent-encoding for certain characters as specified in RFC3986 Section 2.1.
markus_sabadello: In did resolution there are algorithms for how to handle relativeRef and other parts of the DID URL
… Based on language in the specs, I still think both versions are valid
<manu> yes, relativeRef is defined in DID Resolution -- not DID Core -- we need to solve this in DID Resolution: https://
markus_sabadello: Thats what I think the algs in DID resolution reflect right now
… This might be mistaken. Please review them
<Zakim> JoeAndrieu, you wanted to agree relativeRef should be defined somewhere (extension) before we use it in an example
JoeAndrieu: We do define a parameter definition of relativeRef in DID core
manu: Not in 1.1 that got moved to DID resolution
ottomorac: thanks all
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/