Re: DID 'service' ABNF

Markus, I think your are correct, and that the first option you suggest is
the best one. I'd tweak the rule name slightly to this:

  did-reference      = did *[ ";" did-service ]* [ "/" did-path ] [ "?"
did-query ] [ "#" did-fragment ]
  did                = "did:" method ":" specific-idstring

But your core point stands, which is that the did service name is not part
of the DID itself.

Thanks,

=Drummond


On Sun, Feb 18, 2018 at 5:04 AM, Markus Sabadello <markus@danubetech.com>
wrote:

> I implemented a parser for DID syntax based on the ABNF:
>
> https://github.com/decentralized-identity/universal-resolver/tree/
> master/implementations/java/uni-resolver-core/src/main/
> java/uniresolver/did
>
> And one piece of feedback I have is that perhaps we want to change this:
>
>   did-reference      = did [ "/" did-path ] [ "?" did-query ] [ "#"
> did-fragment ]
>   did                = "did:" method ":" specific-idstring *[ ";" service
> ]*
>
> To:
>
>   did-reference      = did *[ ";" service ]* [ "/" did-path ] [ "?"
> did-query ] [ "#" did-fragment ]
>   did                = "did:" method ":" specific-idstring
>
> This wouldn't change the allowed syntax, only re-organize the rules, since
> the "service" name isn't really part of the "DID" itself, or?
>
> Or we could also introduce an intermediary rule:
>
>   did-reference      = *did-service* [ "/" did-path ] [ "?" did-query ] [
> "#" did-fragment ]
>   *did-service*        = did *[ ";" service ]*
>   did                = "did:" method ":" specific-idstring
>
> Or:
>
>   did-reference      = *( did / did-service ) *[ "/" did-path ] [ "?"
> did-query ] [ "#" did-fragment ]
>   *did-service*        = did *";" service*
>   did                = "did:" method ":" specific-idstring
>
> Markus
> On 02/18/2018 12:51 AM, =Drummond Reed wrote:
>
> On Fri, Feb 16, 2018 at 10:18 AM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> Hey Drummond,
>>
>> After much friendly yelling back and forth at DB HQ :), I think Dave
>> Longley has convinced me that I'm overly concerned about the service ABNF.
>>
>> I still feel uneasy about it, but I think the onus is on those of us
>> that are concerned to provide concrete examples of where everything
>> falls apart and for those that are not concerned to demonstrate why the
>> examples are not a problem.
>>
>
> Yes, let's do this.
>
>
>>
>> Let's get this into an issue and take the conversation from there, but
>> I'm less against the concept than I was yesterday, and here's why:
>>
>> The argument that was most compelling to me was that the service
>> description goes in the "authority" section of the DID URL:
>>
>> did:METHOD:AUTHORITY?query2=param2&query2=param2#fragment
>>
>> Where AUTHORITY contains the service description. While ChristopherA is
>> correct that things after METHOD are typically the purview of the
>> AUTHORITY section, we're making an exception in this case because things
>> starting at the path are typically service specific. So, we're basically
>> saying, if you're going to do services in your DID Method, you MUST do
>> them in this way... and we're putting that at the DID Spec layer.
>>
>
> Exactly.
>
>
>>
>> Again, I find this a bit sloppy,
>
>
> Ironically, having worked on URI-based specs (RFC 3986) for 15 years now,
> I find it very elegant. But explaining why is probably more easily
> discussed in person at RWOT.
>
>
>> but don't have a better suggestion. We
>> do what I was suggesting, which was to use ? or & because those
>> typically go in a path AFTER the AUTHORITY section.
>>
>
> Right.
>
>
>>
>> In any case, we need more examples of services and non-services
>> expressed through a DID before we can really reach a conclusion on this.
>>
>
> Happy to help prepare some to go over on the list or on RWOT.
>
> =Drummond
>
>
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: The State of W3C Web Payments in 2017
>> http://manu.sporny.org/2017/w3c-web-payments/
>>
>>
>
>
>

Received on Monday, 19 February 2018 06:01:39 UTC