[Openid-specs-ab] Editors: Please rectify the drafts titles ASAP

[Mike Jones]

(moving the working group to bcc in this reply)

Nat, while I know that your intentions are good, I believe that I have to correct the impression your message gives that the editors of our specs have not been following OpenID Foundation spec formatting rules.  I’m writing this reply in my capacity as OpenID Board Secretary – where one of my roles is to ensure that our published specifications follow OpenID Foundation practices.

I’m not going to go into every detail on this working group thread, as this is really a discussion that should happen among the active editors across the active working groups (which is why I moved this WG to bcc).  But I believe we’ve done a good job ensuring that the differences between drafts and Final Specifications are clear.  Drafts include the word “Draft” or “Internet-Draft” in the draft headings and/or title and have a draft number.   (The different placement of these status indicators largely has to do with different tooling, with xml2rfc v1, v2, and v3 all treating headers somewhat differently and the multiple Markdown toolchains we use likewise having differences.) Final specifications likewise use the word “Final” (for instance, see https://openid.net/specs/openid-connect-prompt-create-1_0.html) and do not have a draft number.  These same conventions are used by all working groups (c.f. https://openid.net/specs/fapi-2_0-security-02.html).

Are there things we can do better?  Yes.  (We can discuss possibilities among the active editors.)  Is there a crisis?  No.

I stand behind the commendable work of our volunteer editors and thank them for their substantial contributions to the Foundation and the industry.

                                                       Best wishes,
                                                       -- Mike

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Nat Sakimura via Openid-specs-ab
Sent: Wednesday, March 15, 2023 2:23 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: nat <nat at nat.consulting>
Subject: [Openid-specs-ab] Editors: Please rectify the drafts titles ASAP

I noticed that several of this WG's Drafts are not conforming to the practices the OIDF has been following.
Specifically, these drafts and implementer's drafts do not indicate their status in their titles. Unfortunately, they also lack the "Status of this memo" or "Warning" section that indicates that they are drafts and subject to change. This makes them appear as if they are published standards. They should be rectified ASAP.
Drafts
·        OpenID Connect Profile for SCIM Services<https://openid.net/specs/openid-connect-scim-profile-1_0.html> – (Inactive) Defines how to use SCIM with OpenID Connect
·        OpenID for Verifiable Credential Issuance<https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html> – This specification defines an API and corresponding OAuth-based authorization mechanisms for issuance of Verifiable Credentials
·        OpenID Connect UserInfo Verifiable Credentials<https://openid.net/specs/openid-connect-userinfo-vc-1_0.html> – Enables UserInfo responses as Verifiable Credentials
Implementer’s Drafts
·        Self-Issued OpenID Provider V2<https://openid.net/specs/openid-connect-self-issued-v2-1_0.html> – Enables End-users to use OpenID Providers (OPs) that they control [Most recent Implementer’s Draft<https://openid.net/specs/openid-connect-self-issued-v2-1_0-ID1.html>]
·        OpenID for Verifiable Presentations<https://openid.net/specs/openid-4-verifiable-presentations-1_0.html> – This specification defines a mechanism on top of OAuth 2.0 to allow the presentation of claims in the form of verifiable credentials as part of the protocol flow [Most recent Implementer’s Draft<https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-ID1.html>]

Note that these are OK regarding indicating their status on the title. They all have "draft" in their title. Thanks for following the practice.
·        OpenID Connect Claims Aggregation<https://openid.net/specs/openid-connect-claims-aggregation-1_0.html> – Enables RPs to request and Claims Providers to return aggregated claims through OPs
·        OpenID Connect Federation<https://openid.net/specs/openid-connect-federation-1_0.html> – Defines how sets of OPs and RPs can establish trust by utilizing a Federation Operator [Most recent Implementer’s Draft<https://openid.net/specs/openid-connect-federation-1_0-ID3.html>]
·        OpenID Connect Native SSO for Mobile Apps<https://openid.net/specs/openid-connect-native-sso-1_0.html> – Enables native applications by the same vendor to share login information [Most recent Implementer’s Draft<https://openid.net/specs/openid-connect-native-sso-1_0-ID1.html>]
Best,
--
Nat Sakimura
OpenID AB/Connect WG Co-chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230315/cd756c56/attachment-0001.html>