Re: Subject Identifiers (IETF SECEVENT)

> Is there a reason to differentiate semantics between DID URI and other
URI?

Following the example above I would assume the resulting syntax to be
something like the below

{
     "format": "did",
     "uri": "did:example:12345"
}

Is that what you mean by differentiate? Or are you questioning the need for
the field format in the first place as the URI itself includes the ability
to understand the "format"?

> I agree with Markus, a single identifier format called 'did' whose value
can be any DID URL (which includes bare DIDs)

Could someone elaborate on a use case where a DID URL would be required in
this context? My understanding is that this work would be defining DIDs as
a valid form of subject identifier, where I would assume the concept of
subject from the draft maps to the concept of the DID subject within DID
Core? Because a DID is sufficient to identify the DID subject, what would
allowing a DID URL provide?

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Tue, Apr 13, 2021 at 10:58 AM Tom Jones <thomasclinganjones@gmail.com>
wrote:

> Most existing systems will barf on a did, which is already a url. So a did
> url is a url url, whatever that might mean.
>
> thx ..Tom (mobile)
>
> On Mon, Apr 12, 2021, 3:46 PM David Waite <dwaite@pingidentity.com> wrote:
>
>> Is there a reason to differentiate semantics between DID URI and other
>> URI?
>>
>>
>> On Mon, Apr 12, 2021 at 1:05 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>> For what it’s worth, this is what I was leaning towards as well.
>>>
>>> The question about two identifiers was exactly whether we should have
>>> “did” and “didurl” be separate formats.
>>>
>>>  — Justin
>>>
>>> On Apr 12, 2021, at 10:12 AM, Brent Zundel <brent.zundel@evernym.com>
>>> wrote:
>>>
>>> I agree with Markus, a single identifier format called 'did' whose value
>>> can be any DID URL (which includes bare DIDs).
>>>
>>> On Mon, Apr 12, 2021 at 3:44 AM Markus Sabadello <markus@danubetech.com>
>>> wrote:
>>>
>>>> I don't have a very strong opinion here, but I think my
>>>> preference/recommendation would be to add a single identifier format called
>>>> "did", and that its value can be any DID URL (including bare DIDs).
>>>>
>>>> What would we gain by limiting this to bare DIDs only? This would be a
>>>> bit like only allowing domain names instead of arbitrary HTTP URLs.
>>>>
>>>> Markus
>>>> On 11.04.21 22:57, Tobias Looker wrote:
>>>>
>>>> Hey Justin,
>>>>
>>>> Some comments below
>>>>
>>>> > Should the format be “did”?
>>>>
>>>> This makes the most sense to me.
>>>>
>>>> > Should it include just the bare DID, or should it be a DID URL? Do we
>>>> need two identifiers?
>>>>
>>>> I think it should be just the bare DID too. I'm unsure what a second
>>>> identifier would indicate? Are you assuming if it existed this second
>>>> identifier would be a DID URL?
>>>>
>>>> Thanks,
>>>> [image: Mattr website] <https://mattr.global/>
>>>> *Tobias Looker*
>>>> Mattr
>>>> +64 (0) 27 378 0461
>>>> tobias.looker@mattr.global
>>>> [image: Mattr website] <https://mattr.global/> [image: Mattr on
>>>> LinkedIn] <https://www.linkedin.com/company/mattrglobal> [image: Mattr
>>>> on Twitter] <https://twitter.com/mattrglobal> [image: Mattr on Github]
>>>> <https://github.com/mattrglobal>
>>>> This communication, including any attachments, is confidential. If you
>>>> are not the intended recipient, you should not read it - please contact me
>>>> immediately, destroy it, and do not copy or use any part of this
>>>> communication or disclose anything about it. Thank you. Please note that
>>>> this communication does not designate an information system for the
>>>> purposes of the Electronic Transactions Act 2002.
>>>>
>>>>
>>>> On Sun, Apr 11, 2021 at 4:32 AM Dmitri Zagidulin <dzagidulin@gmail.com>
>>>> wrote:
>>>>
>>>>> Justin,
>>>>>
>>>>> Thanks for bringing this to this group's attention -- that seems super
>>>>> important, and like a great opportunity for DID adoption and interop!
>>>>>
>>>>> As for what the format should be - great question. It seems to me that
>>>>> having just a bare did be sufficient. But of course I'm curious to see the
>>>>> discussion on this topic.
>>>>>
>>>>> Dmitri
>>>>>
>>>>> On Fri, Apr 9, 2021 at 3:36 PM Justin Richer <jricher@mit.edu> wrote:
>>>>>
>>>>>> The Security Events working group in the IETF (SECEVENT) has a
>>>>>> standards-track draft for describing “subject identifiers” in various
>>>>>> contexts.
>>>>>>
>>>>>>
>>>>>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-07.html
>>>>>>
>>>>>> In short, it’s a way to say “this item is an email and here’s its
>>>>>> value”, or “this item is an issuer/subject pair, here are those values”.
>>>>>> This is useful in a variety of contexts where you want to identify someone
>>>>>> but might have a variety of ways to do so.
>>>>>>
>>>>>> I spoke with the editor of the draft to propose that we add a “did”
>>>>>> format into this document, now that DID core is reasonably stable and the
>>>>>> CR is published. She agreed that it would make sense but would rather have
>>>>>> the experts in the DID community propose the actual text for the added
>>>>>> section. For comparison, this is the current text for the “acct:” URI
>>>>>> scheme:
>>>>>>
>>>>>>    The Account Identifier Format identifies a subject using an account
>>>>>>    at a service provider, identified with an "acct" URI as defined in
>>>>>>    [RFC7565 <https://datatracker.ietf.org/doc/html/rfc7565>].  Subject Identifiers in this format MUST contain a "uri"
>>>>>>    member whose value is the "acct" URI for the subject.  The "uri"
>>>>>>    member is REQUIRED and MUST NOT be null or empty.  The Account
>>>>>>    Identifier Format is identified by the name "account".
>>>>>>
>>>>>>    Below is a non-normative example Subject Identifier for the Account
>>>>>>    Identifier Format:
>>>>>>
>>>>>>    {
>>>>>>      "format": "account",
>>>>>>      "uri": "acct:example.user@service.example.com",
>>>>>>    }
>>>>>>
>>>>>>      Figure 4: Example: Subject Identifier for the Account Identifier
>>>>>>                                   Format
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I’m willing to coordinate the pull request against the IETF spec to
>>>>>> get this included, but I’d like to get feedback on what we include. Should
>>>>>> the format be “did”? Should it include just the bare DID, or should it be a
>>>>>> DID URL? Do we need two identifiers? I have a gut instinct for all of these
>>>>>> answers, but I welcome input on the list here and I’d like to take a few
>>>>>> minutes to discuss this on the upcoming Tuesday call.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>>>>
>>>>
>>>
>>> --
>>> Brent Zundel, Evernym
>>> Chief Cryptography Architect
>>> Open Standards Architect
>>>
>>>
>>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>
>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.