First iteration of Event Def Spec #209
Conversation
|
|
||
| 1. Author(s) of the pull request MUST be at least a contributing member of the OpenID Foundation. | ||
| 1. The Pull Request MUST contain a human readable description of the new SSF event type. | ||
| 1. The $id of the schema MUST be publicly accesbile on the internet and resolve to the schema document. |
There was a problem hiding this comment.
Do we need to worry about broken or stale URLs? Should there be a process for handling those?
| 1. The $id of the schema MUST be publicly accesbile on the internet and resolve to the schema document. | ||
| 1. The "title" and "description" of the schema must be meaningful and indicative of its function. | ||
| 1. The naming of all schema properties MUST be indicative of its function. | ||
| 1. Schemas may not be removed, only deprecated. Any changes to schemas must follow semantic versioning. |
There was a problem hiding this comment.
How will we mark schemas as deprecated?
There was a problem hiding this comment.
schemas cannot be deprecated explicitly but superseded by newer versions
[edit] : im actually not sure about this... lets discuss today
|
|
||
| This section serves as a registry for the schemas of all registered SSF Event Types. | ||
|
|
||
| | Event Type | Schema URI | Description |
There was a problem hiding this comment.
My goal with this effort was to eliminate the need for this classification. An event should be descriptive enough to not need a bucket.
| ~~~ json | ||
| { | ||
| "$schema":"https://json-schema.org/draft/2020-12/schema", | ||
| "$id":"https://schemas.openid.net/secevent/caep/event-type/session-revoked/v1.schema.json", |
There was a problem hiding this comment.
I think we might need to define a mapping of the event identifier in the SET to the JSON schema identifier.
E.g. the event identifier is $id with .schema.json stripped?
And then we can say the inverse: an event's schema can be found by appending .schema.json to the event identifier and then dereferencing it.
There was a problem hiding this comment.
i think thats a good idea.
| 1. Author(s) of the pull request MUST be at least a contributing member of the OpenID Foundation. | ||
| 1. The Pull Request MUST contain a human readable description of the new SSF event type. | ||
| 1. The $id of the schema MUST be publicly accesbile on the internet and resolve to the schema document. |
There was a problem hiding this comment.
An alternative is that we use issues with issue templates, so we can require certain information be provided.
Co-authored-by: Tim Cappalli <[email protected]> Co-authored-by: Shayne Miel (he/him) <[email protected]>
Co-authored-by: Tim Cappalli <[email protected]> Co-authored-by: Shayne Miel (he/him) <[email protected]>
|
This is a great start, @jischr ! I would like to understand how a collection of events can be defined and identified as such here. For example, if someone wanted to implement "session security", then there may be many events that come under that collection (today named CAEP). Would there be a way to identify that in this scheme? |
@tulshi We could refer to this "Collection" in a new schema that described the whole events array. I think the big takeaway from your comment is the distinction between event definitions and collections of event definitions. Let me rough draft how that could look! |
Wouldn't this just be addressed via an interop profile? Each event should be able to stand on its own in terms of understanding its usage. I don't think we should formally group events in this new model. We already have |
This PR addresses #158