Re: Subject Identifiers (IETF SECEVENT)

On Tue, Apr 13, 2021 at 6:20 AM Justin Richer <jricher@mit.edu> wrote:

> The goal of the subject identifiers draft under discussion is to have a
> tagged identifier format that allows for structured data, beyond just
> strings. Saying “it’s a URI” just punts the format question down to another
> layer to answer, and so that isn’t that helpful for users of this spec. I
> see little value in a generic URI format, as a consequence, and there are
> already a number of items that either are or can be encoded as URIs in the
> spec. While you’re correct that this could all just be “it’s a URI”, that’s
> just not a useful statement to make.
>

While I agree that the group has identifiers without an existing URI
structure, has chosen to use identifiers with an existing URI structure
instead as non-URIs, and could have types which convey existing semantic
meaning beyond the 'scheme' of a URI - having potentially multiple types
used to duplicate and allow selection upon schemes seems like just
additional complexity and potential for misinterpretation by
implementations.

To ask my question differently, without using the subject identifier type
of "did", how would you convey the semantics of this URI type compared to a
generalized URI type?

For instance, if it is that the DID can be used to cryptographically verify
the subject, does that mean that only the subset of DID URI that resolve to
appropriate cryptographic metadata under an appropriate purpose would
qualify, while the rest would use a different identifier type?

-DW


> This isn’t just about syntax of the value, it’s about the semantics of it.
>
>  — Justin
>
> On Apr 13, 2021, at 3:18 AM, David Waite <dwaite@pingidentity.com> wrote:
>
> The idea behind URI is that they are a uniform representation of
> identifiers. I can understand not all identification schemes can be
> represented within a single URI, but I'm not sure why a single URI-based
> identifier would need additional classification. (e.g. did vs acct vs https)
>
> If the goal is to _also_ leverage format as a way to query or indicate
> supported identifier types, you will likely need more than "did" to
> indicate/request such, as there will likely be deployments which decide not
> to support every registered DID method for various reasons.
>
> -DW
>
> On Mon, Apr 12, 2021 at 7:31 PM Justin Richer <jricher@mit.edu> wrote:
>
>> Yes, it’s a specific kind of identifier with its own internal format
>> rules and semantics. A system might be able to understand DIDs and request
>> that identifier format specifically, while others wouldn’t know a DID but
>> could handle a different kind of URI.
>>
>>  — Justin
>>
>> On Apr 12, 2021, at 6:44 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.*
>>
>>
>>
> *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.*
>
>
>

-- 
_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._