[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Sorry to have abruptly dropped off the call. Here are the notes from
today's call. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20230815>.

Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

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

WG Meeting: 2023-08-15
 Comment
<https://hackmd.io/kxR5KXuvTQKHqFaLFzbmwA#Agenda>Agenda

   - Versioning proposal
   - Remove authorization scopes / URLs from SSF metadata
   - Comments in “Sub_id” PR
   <https://github.com/openid/sharedsignals/pull/82/files>

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

   - Atul Tulshibagwale (SGNL)
   - Asad Ali (Thales)
   - Steve Venema (ForgeRock)
   - Apoorva Deshpande (Okta)
   - Tim Cappalli (Microsoft)
   - Peter Travers (Beyond Identity)
   - Mike Kiser (SailPoint)
   - Phil Hunt (Independent ID)

<https://hackmd.io/kxR5KXuvTQKHqFaLFzbmwA#Notes>Notes
<https://hackmd.io/kxR5KXuvTQKHqFaLFzbmwA#Versioning-Proposal>Versioning
Proposal

   - How do we document what has changed between versions?
      - We can tag releases on GitHub with the changes
      - The tag should say which release version of the document it refers
      to.
      - Typically handled in non-spec output (e.g. blog posts)
      - Ideally every change has an associated GitHub issue, and we can
      just capture the list of issues that have been addressed.
   - Breaking vs. Non-breaking changes
      - We could have normative text that specifies implementers should
      ignore any unknown additional claims
      - How do we ascertain compliance?
      - Breaking should imply that an existing deployment would no longer
      work with a newer version
      - Proposed wording: “Must ignore claims or attributes that are not
      understood”
      - Is there some reference language we can borrow?
      - There’s an old BCP? In the IETF
      - The JWT spec has text in it.
   - We had discussions about document version / protocol version
   correlation
      - We should not do this.
      - A variation of the question is: As we’re iterating on a version,
      what do we do in the interim
      - All versions in the interim (before an approved version is
      released) reference a same version number
   - We might want to title the doc “protocol versioning”
      - What does it mean to change a dictionary (e.g. the set of events
      described in the CAEP spec)
      - Any change to a dictionary is a protocol / schema revision
      - How would a Receiver know which dictionary version is supported by
      the Transmitter?
      - Phil: just do version by dictionary, but include in each URN
      - Tim: agreed, then doc can match event versions
      - Tim: matches current OIDF process of being in a spec
      - Also need a versioning guide (or section) specifically for event
      dictionaries as they differ from protocol versions
      - Steve: could also have the same event listed with different
      versions in metadata if Tx supports two versions of the dictionary
      - Steve: What if only 1 event changes in a dictionary update?
      - Phil: change them all for conveinance
      - Need use cases for version changes of events vs dictionary
      - Tim: one question is whether rev-ing a version of an event when it
      didn’t change is as a bad thing

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

   - Atul to incorporate text from the JWT spec for specifying what is
   backward compatibility. Get consensus and add it to the spec.
   - Steve to write up use cases for event version changes
   - All: review issue #95 before next call per Apoorva’s request
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230815/679a1ef2/attachment-0001.html>