Re: Subject Identifiers (IETF SECEVENT)

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.

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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,
>>>>  <https://mattr.global/>   
>>>> Tobias Looker
>>>> Mattr
>>>> +64 (0) 27 378 0461
>>>> tobias.looker@mattr.global <mailto:tobias.looker@mattr.global>
>>>>  <https://mattr.global/>  <https://www.linkedin.com/company/mattrglobal>  <https://twitter.com/mattrglobal>  <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 <mailto: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 <mailto: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 <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 <mailto: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.

Received on Tuesday, 13 April 2021 12:21:18 UTC