[Openid-specs-risc] Call notes
Atul Tulshibagwale
atultulshi at google.com
Tue Feb 16 20:24:44 UTC 2021
Hi all,
Here are the notes I took in the working group call today. As always, the
notes are available here
<https://docs.google.com/document/d/1ZFwJJDwwSBNKX35VObClC1ctMbMMuHJtr5qY-7xsLW8/edit?usp=sharing>
Call on 2/16/2021
Attendees:
-
Atul (Google)
-
Matt (Sailpoint)
-
Tim (Microsoft)
Agenda:
-
Event timestamp in SSE events
-
Genericizing the “user-device-session” subject identifier type to be
more of a “compound subject identifier type”
-
Review rest of Matt’s comments
Notes:
-
Can we use the SET “time of event” (toe) claim?
-
We may not be able to use the “toe” claim because it is in seconds,
whereas we need a timestamp that is in either milliseconds or microseconds.
Tim to look into this.
-
Described the notion of a “compound subject identifier”. It should
describe one subject, and all components of a compound subject must be
ANDed to identify the subject.
-
Atul to send draft proposal to the working group
-
Should the subject_type be “iss-sub” or “iss_sub”. [SUBIDS] seems to use
the underscore. Should the SUBIDS draft be updated or the SSE draft be
updated? Determined in the call to use the underscore.
-
Should the “claims changed” event have a current and new values?
Assumption is that the sender has the current value, so we need not include
it in the event.
-
To handle concurrency, we will rely on the time of the event rather than
specifying a current value to a claim.
-
Open question: Should we have a recommendation / requirement in the SSE
spec (not event types spec) regarding the use of the event timestamp? I.e.
should we require that a receiver must ignore events that modify specific
claims for a specific subject that have been modified as a result of
processing an event with a later timestamp?
-
Number of examples are not matching the event type definitions. Atul to
update the examples to match the current event types spec
Atul Tulshibagwale
Software Engineer,
Google Workspace
atultulshi at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20210216/595a9ba3/attachment.html>
More information about the Openid-specs-risc
mailing list