[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes from yesterday's call. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20230808>:

Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>

WG Meeting: 2023-08-08 <https://hackmd.io/XRdbRSNhQzm2jNE37I0VvQ#Agenda>
Agenda

   - (atul) Backwards compatibility
   - (smiel) Why do we have a format field in the Stream Configuration? PR
   87 discussion
   <https://github.com/openid/sharedsignals/pull/87#discussion_r1276951345>
   - (Apoorva) Metadata key changes PR 96
   <https://github.com/openid/sharedsignals/pull/96>
   - (Apoorva) CAEP usecases PR 92
   <https://github.com/openid/sharedsignals/pull/92> (2/7 meeting notes
   refer to this doc
   <https://docs.google.com/document/d/1tmMqiXNB-lW9HXIzrivOvaFSts23zAzKLWPcSD740kE/edit#heading=h.fsduc31pruxn>
any
   update on this?)
   - (Apoorva) is receiver allowed to set empty events requested in a PUT?
   Should this be 400?

<https://hackmd.io/XRdbRSNhQzm2jNE37I0VvQ#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Steve Venema (ForgeRock)
   - Phil Hunt (Independent ID)
   - Eric Karlinsky (Okta)
   - Tim Cappalli (Microsoft)
   - Yair Sarig (VMWare)
   - Apoorva Deshpande (Okta)

<https://hackmd.io/XRdbRSNhQzm2jNE37I0VvQ#Notes>Notes
<https://hackmd.io/XRdbRSNhQzm2jNE37I0VvQ#Backwards-Compatibility>Backwards
Compatibility

   - (Tim) Are the 100s of thousands of Google partners just those that use
   the Firebase SDK
   - (Tim) So Google could just update the SDK
   - (Phil) Revving an SDK is not hard, so Google could do that
   - (Yair) Many will take a long time to make the change
   - (Atul) We can add a “version” or some such field in the Transmitter
   Configuration Metadata. Presence of this field will indicate that it is the
   new version of the spec, if the field is absent then it is the current RISC
   spec.
   - (Apoorva) Can we enumerate the breaking changes
   - (Tim) We should not codify the version numbers in implementer’s drafts
   - (Phil) We could do major / minor versions. Right now we are at “0.x”
   - (Phil) We could make the major version change change the numeral
   before the dot
   - (Tim) Three questions:
      - What does the version represent?
      - When do we rev the version?
      - What’s the field called?
   - (Phil) Most companies don’t like to say they are implementing a
   standard
   - (Steve) We’re talking about interop between companies
   - (Phil) “I support” versus “I guarantee” (a lot don’t although they
   should)
   - (Phil) It’s the certification, not the language
   - (Atul) Can we say that if the “version” field is not present, then it
   is a specific older version of the draft
   - (Tim) We can say that anything that doesn’t have the version field,
   then we could say generically it is a pre-standard implementation
   - (Yair) You do not want local progression so that each implementation
   has some different version that was published in the past
   - (Steve) What is a backward compatible change and what isn’t?
   - (Phil) Backward incompatible changes should rev the spec version,
   others should not
   - (Phil) Schema number should be distinct from the approval process - so
   that when a draft that is currently implemented doesn’t get a new number
   without anything changing in the spec
   - (Phil) There are three numbers that matter: Formal document version
   number. There’s the protocol version number, and there’s the schema changes.
   - (Steve) Doesn’t the protocol change mean that the schema has changed?
   - (Phil) Only change the number if it matters to an implementer
   - (Atul) Proposal: We add a field in the metadata and assign a verison
   number “1” to it, even though the current draft is not ratified by the
   OpenID foundation as a standard. If we need to make a backward compatible
   change that is published as an implementer’s draft, then we update the
   number to the right of the decimal (i.e. 1.1, 1.2, etc.) This way, when a
   spec goes from an implementer’s draft to a final draft, we do not have to
   change the version number.
   - (?) How do we revision events in CAEP / RISC?
   - (Steve) Someone should write a concrete proposal
   - (Tim) There’s core-framework versions and there’s event versions
   - (Tim) Phil - on the event Identifier, would it be better to use URNs
   instead of URIs, since they have version numbering in them
   - (Phil) When we register with the IETF (IANA?) they’re always URNs.
   - (Phil) We could establish a new IANA registry in this working group
   with an apporpriate naming convention and process
   - (Phil) Anyone can register their own namespace.
   -

<https://hackmd.io/XRdbRSNhQzm2jNE37I0VvQ#Action-Items>Action Items

   - Atul to provide a proposal for core-framework versioning as a Google
   Doc
   - Tim to provide a proposal for event versions as a GitHub issue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230809/255a1557/attachment-0001.html>