[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

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

Thanks to those who attended.
Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

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


WG Meeting: 2023-10-03
<https://hackmd.io/y31UIH5qTbazcZryWQ9Eyg?view#Agenda>Agenda

   - Versioning update <https://github.com/openid/sharedsignals/issues/124>
   - When do we vote on this draft?

<https://hackmd.io/y31UIH5qTbazcZryWQ9Eyg?view#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Yair Sarig (VMWare)
   - Tim Cappalli (Microsoft)

<https://hackmd.io/y31UIH5qTbazcZryWQ9Eyg?view#Notes>Notes
<https://hackmd.io/y31UIH5qTbazcZryWQ9Eyg?view#Versioning>Versioning

   - (Tim) It’s surprising we need to address this before we get to a final
   spec
   - (Atul) A little bit of work can help exisitng implementations adhere
   to standards
   - (Yair) The examples mentioned are extensions, and not a part of the
   core spec, so I’m not sure the example applies.
   - (Atul) Although the examples are non-core to OAuth, the mechanism for
   indicating features in metadata can address the issue
   - (Tim) Using feature names is going to require a lot of thought.
   - (Yair) Agree. How will we come up with these names
   - (Atul) I don’t have an answer to that
   - (Yair) It’s not just coming up with a name, it is what does it mean
   - (Tim) E.g. in “sub_id at top level”
   - (Tim) We should come up with a pattern, either descriptive names or
   boolean variables, and what are the defaults
   - (Atul) I can create a PR that takes the “boolean” approach
   - (Atul) to address Shayne’s dependency question: It should be the
   Transmitter’s responsibility to create consistent metadata that doesn’t
   contradict itself.
   - (Tim) We could use version numbers for core features and use feature
   flags for optional features
   - (Tim) We can introduce an object in the metadata that lists the
   features that the Transmitter does not support
   - (Tim) Why not introduce a “spec_version” claim in the Transmitter
   Configuration Metadata that just has the proposed version number of ID2
   (i.e. “1_0-ID2”)
   - (Yair) The spec already has ways to indicate which optional features
   (e.g. status endpoint) are supported

<https://hackmd.io/y31UIH5qTbazcZryWQ9Eyg?view#Voting-on-Current-Draft>Voting
on Current Draft

   - (Tim) We should just announce on the list that we are at a cutoff
   point for the ID2.
   -

<https://hackmd.io/y31UIH5qTbazcZryWQ9Eyg?view#Action-Items>Action Items

   - Atul to write PR to incorporate “spec_version” in Transmitter
   Configuration Metadata
   - Tim to post an update with mention of the spec version issue (and any
   way in which the spec may be inimplementable)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20231003/066dd23a/attachment-0001.html>