Subject: [Id-event] Repeat WG last call: Subject Identifiers

From: Yaron Sheffer <[email-masked]>
Date: Wed, 09 Mar 2022 15:54:24 +0200

This is to start a repeat working group last call for draft-ietf-secevent-subject-identifiers [1]. Please respond to the list with your comments, even if they only amount to “I read the draft and it’s fine”.

We solicit and encourage WG feedback. However given the age of the draft and overall low working group energy, the current plan is to progress the draft to the IESG by default, unless any major issues are raised.

As you review the document, please note that two versions (-09 and -10) were published recently. 

The LC will be open until March 20.

Thanks,

                Yaron

[1] https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/

---

From: Denis <[email-masked]>
Date: Wed, 9 Mar 2022 15:54:52 +0100

Yaron,

I read the draft and*it's not fine*.

I am still awaiting the resolution of the comments I posted last year.

IMO, these issues are *major*.

Thanks,

Denis

> This is to start a repeat working group last call for 
> draft-ietf-secevent-subject-identifiers [1]. Please respond to the 
> list with your comments, even if they only amount to “I read the draft 
> and it’s fine”.
>
> We solicit and encourage WG feedback. However given the age of the 
> draft and overall low working group energy, the current plan is to 
> progress the draft to the IESG by default, unless any major issues are 
> raised.
>
> The LC will be open until *March 20*.
>
> Thanks,
>
> Yaron
>
> [1] 
> https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/
>
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Dick Hardt <[email-masked]>
Date: Wed, 9 Mar 2022 07:11:05 -0800

Denis: would you kindly repost your issues referencing sections in the
current document?

On Wed, Mar 9, 2022 at 6:55 AM Denis <[email-masked]> wrote:

> Yaron,
>
> I read the draft and* it's not fine*.
>
> draft-ietf-secevent-subject-identifiers [1]. Please respond to the list
> with your comments, even if they only amount to “I read the draft and it’s
> fine”.
>
>
>
> We solicit and encourage WG feedback. However given the age of the draft
> and overall low working group energy, the current plan is to progress the
> draft to the IESG by default, unless any major issues are raised.
>
>
>
> Id-event mailing [email-masked]://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Dave Tonge <[email-masked]>
Date: Sun, 13 Mar 2022 21:05:05 +0100

I have read the draft and I support its publication

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2022 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Prachi Jain <[email-masked]>
Date: Sun, 13 Mar 2022 22:20:36 -0500

Thanks for your support, Dave !!

-Prachi

On Sun, Mar 13, 2022 at 3:05 PM Dave Tonge <[email-masked]>
wrote:

> Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Moneyhub Financial Technology Limited 2022 ©
> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1
> 6EA.
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all

---

From: Justin Richer <[email-masked]>
Date: Sun, 20 Mar 2022 10:57:23 +0100

I support the publication of this document.

 — Justin

> On Mar 9, 2022, at 2:54 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/ <https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Mike Jones <[email-masked]>
Date: Sun, 20 Mar 2022 13:58:55 +0000

I support publication of this draft following a few revisions.  I’d like comments below to be addressed first.

NORMATIVE

Section 3 (Subject Identifiers) says “A Subject Identifier MUST NOT contain any members prohibited or not described by its Identifier Format, and MUST contain all members required by its Identifier Format.”  This is not normal JSON usage; normal JSON usage would allow additional members to be present and say that they must be ignored if not understood.  We should consider making this change.  At the very least, formats should be allowed to define that their elements are extensible.

Section 3.2.3 defines a DID URL format.  There’s nothing special here about a DID URLs that would make them different than other URLs.  Please revise this section to instead define either a “url” or “uri” format.  It would be fine to say that DID URLs are one kind of URL or URI that could be used, just as https URLs would be.  That would be more general and would still allow the use of DID URLs as subject identifiers.

EDITORIAL

“general purpose” -> “general-purpose”

RFC 7159 is listed twice in the Definitions section.

It’s customary to acknowledge individual reviewers of the specification by name.  Please do so.

                                                       Best wishes,
                                                       -- Mike

From: Id-event <[email-masked]> On Behalf Of Yaron Sheffer
Sent: Wednesday, March 9, 2022 2:54 PM
To: [email-masked]
Subject: [Id-event] Repeat WG last call: Subject Identifiers

Thanks,
                Yaron

---

From: Aaron Parecki <[email-masked]>
Date: Sun, 20 Mar 2022 15:33:24 +0100

I agree with Mike. Section 3.2.3 should be revised to be a URI/URL format
since DIDs are a type of URIs. If you think it would be helpful to the DID
community, this section could specifically call out that DIDs are a type of
URL with the examples in the current draft.

The introduction section talks about IP address and MAC address as
identifiers as well, but those are not listed as identifier formats. Was
that an intentional omission?

Editorial: I realize the list of identifier format definitions is sorted
alphabetically, but I personally found it awkward that the "aliases" type
was the second one listed. I think it would read better if the "aliases"
type were the last one in the list.

Aaron

On Sun, Mar 20, 2022 at 2:59 PM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> Section 3 (Subject Identifiers) says “A Subject Identifier MUST NOT
> contain any members prohibited or not described by its Identifier Format,
> and MUST contain all members required by its Identifier Format.”  This is
> not normal JSON usage; normal JSON usage would allow additional members to
> be present and say that they must be ignored if not understood.  We should
> consider making this change.  At the very least, formats should be allowed
> to define that their elements are extensible.
>
>
>
> Section 3.2.3 defines a DID URL format.  There’s nothing special here
> about a DID URLs that would make them different than other URLs.  Please
> revise this section to instead define either a “url” or “uri” format.  It
> would be fine to say that DID URLs are one kind of URL or URI that could be
> used, just as https URLs would be.  That would be more general and would
> still allow the use of DID URLs as subject identifiers.
>
>
>
> EDITORIAL
>
>
>
> *From:* Id-event <[email-masked]> *On Behalf Of *Yaron Sheffer
> *Sent:* Wednesday, March 9, 2022 2:54 PM
> *To:* [email-masked]
> *Subject:* [Id-event] Repeat WG last call: Subject Identifiers
>
>
>
> The LC will be open until * March 20*.
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> [1]

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 20 Mar 2022 17:13:27 +0200

(Hats off)

Hi Mike,

To your first point, this is not a security protocol. Rather it is a definition of a security-critical part of potentially several security protocols. As such, protocols can and should each define the degree of extensibility that works for them. But I disagree with your assertion that a generic identifier type should be extensible just because the JSON format has great support for extensibility. If needed, protocols can define extensibility points *outside* the subject identifier.

To my understanding, your proposal “formats should be allowed to define that their elements are extensible” is addressed by the preceding paragraph, albeit not with full unrestricted extensibility:

An Identifier Format MAY describe more members than are strictly necessary to identify a subject, and MAY describe conditions under which those members are required, optional, or prohibited.  

Thanks,

                Yaron

From: Mike Jones <[email-masked]>
Date: Sunday, March 20, 2022 at 15:58
To: Yaron Sheffer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Repeat WG last call: Subject Identifiers

NORMATIVE

EDITORIAL

                                                       Best wishes,

                                                       -- Mike

Thanks,

                Yaron

---

From: Justin Richer <[email-masked]>
Date: Fri, 25 Mar 2022 18:52:44 +0100

I disagree with Mike and Aaron on this point. We also have acct: URIs in there as an option. Email addresses and phone numbers could also be expressed as URIs, if we want to take this logic to the extreme.  I don’t see value in pushing the semantics down a level — this is a spec about telling you some level of detail about what the kind of thing is.

All that said, a generic “uri” would be a fine addition, but not at the expense of removing “did” or other more specific formats.

On the editorial nit: I agree that “aliases” should be last in the listing.

 — Justin

> On Mar 20, 2022, at 3:33 PM, Aaron Parecki <[email-masked]> wrote:
> 
> I agree with Mike. Section 3.2.3 should be revised to be a URI/URL format since DIDs are a type of URIs. If you think it would be helpful to the DID community, this section could specifically call out that DIDs are a type of URL with the examples in the current draft.
> 
> The introduction section talks about IP address and MAC address as identifiers as well, but those are not listed as identifier formats. Was that an intentional omission?
> 
> Editorial: I realize the list of identifier format definitions is sorted alphabetically, but I personally found it awkward that the "aliases" type was the second one listed. I think it would read better if the "aliases" type were the last one in the list. 
> 
> Aaron
> 
> 
> On Sun, Mar 20, 2022 at 2:59 PM Mike Jones <Michael.Jones=[email-masked] <mailto:[email-masked]>> wrote:
> From: Id-event <[email-masked] <mailto:[email-masked]>> On Behalf Of Yaron Sheffer
> To: [email-masked] <mailto:[email-masked]>