First iteration of Event Def Spec #209

jischr · 2024-09-24T16:52:39Z

This PR addresses #158

appsdesh · 2024-09-25T19:52:52Z

openid-sharedsignals-eventdef-specification-1_0.md

+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.
+


Should we specify JSON schema for the SET and call out all the mandatory claims of the SET are required? This will help developers to generate entire container objects, rather than only the sub-object events

That would greatly complicate these schemas and also make it impossible to ever change the details of SET specification in the SSF spec.

FragLegs · 2024-10-02T15:13:29Z

openid-sharedsignals-eventdef-specification-1_0.md

+This specification defines how to translate normative SSF, CAEP, RISC event requirements into a JSON Schema. {{JSONSchema}} is a standardized way to describe the structure, constraints, and data types within a JSON document. JSON Schemas can also be used as {{JSONSchemaValidation}} to automatically check if a JSON document adheres to the defined schema, ensuring data integrity.
+
+Using JSON Schema to describe SSF has the following benefits:
+- Allows machine readability to auto generation of stubs.


Suggested change

- Allows machine readability to auto generation of stubs.

- Allows machine readability for the auto generation of stubs.

FragLegs · 2024-10-02T15:14:03Z

openid-sharedsignals-eventdef-specification-1_0.md

+- It enables a faster process to create, update and get approval for new event types. 
+- JSON schema, rather than spec texts, is a more appropriate format to describe event types. 
+- It also allows event types to be versioned independently thus reducing the friction between the SSF core specification and event type publication.
+- Allows more events to be incorporated easily in the standards space beyond the usecases and charters of CAEP, RISC etc.


Suggested change

- Allows more events to be incorporated easily in the standards space beyond the usecases and charters of CAEP, RISC etc.

- Allows more events to be incorporated easily in the standards space beyond the use cases and charters of CAEP, RISC etc.

FragLegs · 2024-10-02T15:14:27Z

openid-sharedsignals-eventdef-specification-1_0.md

+
+# JSON Schema Defintion
+
+The following section describes how a map a SSF event to a JSON Schema Document.


Suggested change

The following section describes how a map a SSF event to a JSON Schema Document.

The following section describes how to map a SSF event to a JSON Schema Document.

FragLegs · 2024-10-02T15:18:22Z

openid-sharedsignals-eventdef-specification-1_0.md

+
+The following section describes how a map a SSF event to a JSON Schema Document.
+
+As defined in {{Section 4.3 of JSON Schema}}, a JSON Schema document, also called a "schema", is a JSON document used to describe another JSON Document, known as an instance.


Do these links work correctly? I thought that the text within the brackets had to match something in the references section. I would expect it to look like Section 4.3 of {{JSONSchema}}, but I could be wrong.

FragLegs · 2024-10-02T15:19:34Z

openid-sharedsignals-eventdef-specification-1_0.md

+
+As defined in {{Section 4.3 of JSON Schema}}, a JSON Schema document, also called a "schema", is a JSON document used to describe another JSON Document, known as an instance.
+
+A JSON Schema document describes the instance of SSF SET event "payload" ({{Section 2 of SET}}). As such, the schema will defined the claims that pertian to the specific SSF event type. The $id for the schema document MUST be the same as the event identifier of the SET.


Suggested change

A JSON Schema document describes the instance of SSF SET event "payload" ({{Section 2 of SET}}). As such, the schema will defined the claims that pertian to the specific SSF event type. The $id for the schema document MUST be the same as the event identifier of the SET.

A JSON Schema document describes the instance of SSF SET event "payload" ({{Section 2 of SET}}). As such, the schema will define the claims that pertain to the specific SSF event type. The $id for the schema document MUST be the same as the event identifier of the SET.

FragLegs · 2024-10-02T15:29:45Z

openid-sharedsignals-eventdef-specification-1_0.md

+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.
+


That would greatly complicate these schemas and also make it impossible to ever change the details of SET specification in the SSF spec.

FragLegs · 2024-10-02T15:31:39Z

openid-sharedsignals-eventdef-specification-1_0.md

+
+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.


Do we need to worry about broken or stale URLs? Should there be a process for handling those?

FragLegs · 2024-10-02T15:32:16Z

openid-sharedsignals-eventdef-specification-1_0.md

+
+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.


Suggested change

1. The $id of the schema MUST be publicly accesbile on the internet and resolve to the schema document.

1. The $id of the schema MUST be publicly accessible on the internet and resolve to the schema document.

FragLegs · 2024-10-02T15:32:56Z

openid-sharedsignals-eventdef-specification-1_0.md

+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.


How will we mark schemas as deprecated?

FragLegs · 2024-10-02T15:35:39Z

openid-sharedsignals-eventdef-specification-1_0.md

+  RFC6711:
+  RFC8176:
+  SSF:
+    target: http://openid.net/specs/openid-sse-framework-1_0.html


This is referencing a very out of date draft. Please update to draft 3: https://openid.net/specs/openid-sharedsignals-framework-1_0-03.html

timcappalli and others added 6 commits June 6, 2024 15:05

initial eventdef skeleton

273a016

starting to scaffold properties

77f865a

specify just event

9782c11

Updates to the spec

e290728

fix terminology

346eb7f

fix registration

6a8d0bf

jischr requested a review from a team as a code owner September 24, 2024 16:52

appsdesh added 2 commits September 25, 2024 11:31

Update openid-sharedsignals-eventdef-specification-1_0.md

954c7d3

Updated example for the Session Revoked JSON Schema

7d20221

appsdesh reviewed Sep 25, 2024

View reviewed changes

FragLegs requested changes Oct 2, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First iteration of Event Def Spec #209

First iteration of Event Def Spec #209

jischr commented Sep 24, 2024

appsdesh Sep 25, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

FragLegs Oct 2, 2024

	- Allows machine readability to auto generation of stubs.
	- Allows machine readability for the auto generation of stubs.

	- Allows more events to be incorporated easily in the standards space beyond the usecases and charters of CAEP, RISC etc.
	- Allows more events to be incorporated easily in the standards space beyond the use cases and charters of CAEP, RISC etc.


		# JSON Schema Defintion

		The following section describes how a map a SSF event to a JSON Schema Document.

	The following section describes how a map a SSF event to a JSON Schema Document.
	The following section describes how to map a SSF event to a JSON Schema Document.


		The following section describes how a map a SSF event to a JSON Schema Document.

		As defined in {{Section 4.3 of JSON Schema}}, a JSON Schema document, also called a "schema", is a JSON document used to describe another JSON Document, known as an instance.


		As defined in {{Section 4.3 of JSON Schema}}, a JSON Schema document, also called a "schema", is a JSON document used to describe another JSON Document, known as an instance.

		A JSON Schema document describes the instance of SSF SET event "payload" ({{Section 2 of SET}}). As such, the schema will defined the claims that pertian to the specific SSF event type. The $id for the schema document MUST be the same as the event identifier of the SET.

	1. The $id of the schema MUST be publicly accesbile on the internet and resolve to the schema document.
	1. The $id of the schema MUST be publicly accessible on the internet and resolve to the schema document.

First iteration of Event Def Spec #209

Are you sure you want to change the base?

First iteration of Event Def Spec #209

Conversation

jischr commented Sep 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment