Shared Signals T. Cappalli Microsoft A. Tulshibagwale SGNL 19 June 2024 OpenID Continuous Access Evaluation Profile 1.0 - draft 03 openid-caep-1_0 Abstract This document defines the Continuous Access Evaluation Profile (CAEP) of the Shared Signals Framework [SSF]. It specifies a set of event types conforming to the Shared Signals Framework. These event types are intended to be used between cooperating Transmitters and Receivers such that Transmitters may send continuous updates using which Receivers can attenuate access to shared human or robotic users, devices, sessions and applications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Considerations . . . . . . . . . . . . . . . . 2 2. Optional Event Claims . . . . . . . . . . . . . . . . . . . . 2 3. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Session Revoked . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Event-Specific Claims . . . . . . . . . . . . . . . . 4 3.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Token Claims Change . . . . . . . . . . . . . . . . . . . 6 3.2.1. Event-Specific Claims . . . . . . . . . . . . . . . . 7 3.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Credential Change . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Event-Specific Claims . . . . . . . . . . . . . . . . 9 3.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Assurance Level Change . . . . . . . . . . . . . . . . . 11 3.4.1. Event-Specific Claims . . . . . . . . . . . . . . . . 12 3.4.2. Examples . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Device Compliance Change . . . . . . . . . . . . . . . . 14 3.5.1. Event-Specific Claims . . . . . . . . . . . . . . . . 14 3.5.2. Examples . . . . . . . . . . . . . . . . . . . . . . 15 3.6. Session Established . . . . . . . . . . . . . . . . . . . 16 3.6.1. Event Specific Claims . . . . . . . . . . . . . . . . 17 3.6.2. Examples . . . . . . . . . . . . . . . . . . . . . . 17 3.7. Session Presented . . . . . . . . . . . . . . . . . . . . 18 3.7.1. Event Specific Claims . . . . . . . . . . . . . . . . 18 3.7.2. Examples . . . . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 Cappalli & Tulshibagwale Standards Track [Page 1] CAEP-Spec June 2024 5. Normative References . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix B. Notices . . . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Document History . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction CAEP is the application of the Shared Signals Profile of IETF Security Events 1.0 [SSF] (SSF Profile) to ensure access security in a network of cooperating providers. CAEP specifies a set of event- types that conform to the SSF Profile. This document specifies the event-types required to achieve this goal. 1.1. Notational Considerations The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Optional Event Claims The following claims are optional unless otherwise specified in the event definition. event_timestamp OPTIONAL, JSON number: the time at which the event described by this SET occurred. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. initiating_entity OPTIONAL, JSON string: describes the entity that invoked the event. This MUST be one of the following strings: * admin: an administrative action triggered the event * user: an end-user action triggered the event * policy: a policy evaluation triggered the event * system: a system or platform assertion triggered the event reason_admin OPTIONAL, JSON object: a localizable administrative Cappalli & Tulshibagwale Standards Track [Page 2] CAEP-Spec June 2024 message intended for logging and auditing. The object MUST contain one or more key/value pairs, with a BCP47 [RFC5646] language tag as the key and the locale-specific administrative message as the value. { "reason_admin": { "en": "Landspeed Policy Violation: C076E82F", "de": "Landspeed-Richtlinienverstoss: C076E82F", "es-410": "Violacion de la politica de landspeed: C076E82F" } } Figure 1: Example: Administrative reason information with multiple languages reason_user OPTIONAL, JSON object: a localizable user-friendly message for display to an end-user. The object MUST contain one or more key/value pairs, with a BCP47 [RFC5646] language tag as the key and the locale-specific end-user message as the value. { "reason_user": { "en": "Access attempt from multiple regions.", "de": "Zugriffsversuch aus mehreren Regionen.", "es-410": "Intento de acceso desde varias regiones." } } Figure 2: Example: End user reason information with multiple languages 3. Event Types The base URI for CAEP event types is: https://schemas.openid.net/secevent/caep/event-type/ 3.1. Session Revoked Event Type URI: https://schemas.openid.net/secevent/caep/event-type/session-revoked Session Revoked signals that the session identified by the subject has been revoked. The explicit session identifier may be directly referenced in the subject or other properties of the session may be included to allow the receiver to identify applicable sessions. Cappalli & Tulshibagwale Standards Track [Page 3] CAEP-Spec June 2024 When a Complex Claim is used as the subject, the revocation event applies to any session derived from matching those combined claims. The actual reason why the session was revoked might be specified with the nested reason_admin and/or reason_user claims described in Section 2. 3.1.1. Event-Specific Claims There are no event-specific claims for this event type. When event_timestamp is included, its value MUST represent the time at which the session revocation occurred. 3.1.2. Examples NOTE: The event type URI is wrapped, the backslash is the continuation character. { "iss": "https://idp.example.com/123456789/", "jti": "24c63fb56e5a2d77a6b512616ca9fa24", "iat": 1615305159, "aud": "https://sp.example.com/caep", "txn": 8675309, "sub_id": { "format": "opaque", "id": "dMTlD|1600802906337.16|16008.16" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/session-revoked": { "event_timestamp": 1615304991643 } } } Figure 3: Example: Session Revoked - Required claims + Simple Subject Cappalli & Tulshibagwale Standards Track [Page 4] CAEP-Spec June 2024 { "iss": "https://idp.example.com/123456789/", "jti": "24c63fb56e5a2d77a6b512616ca9fa24", "iat": 1615305159, "aud": "https://sp.example.com/caep", "txn": 8675309, "sub_id": { "format": "complex", "session": { "format": "opaque", "id": "dMTlD|1600802906337.16|16008.16" }, "user": { "format": "iss_sub", "iss": "https://idp.example.com/123456789/", "sub": "99beb27c-c1c2-4955-882a-e0dc4996fcbc" }, "tenant": { "format": "opaque", "id": "123456789" } }, "events": { "https://schemas.openid.net/secevent/caep/event-type/session-revoked": { "initiating_entity": "policy", "reason_admin": { "en": "Landspeed Policy Violation: C076E82F" }, "reason_user": { "en": "Access attempt from multiple regions.", "es-410": "Intento de acceso desde varias regiones." }, "event_timestamp": 1615304991643 } } } Figure 4: Example: Session Revoked - subject as `sub` claim (includes optional claims) Cappalli & Tulshibagwale Standards Track [Page 5] CAEP-Spec June 2024 { "iss": "https://idp.example.com/123456789/", "jti": "24c63fb56e5a2d77a6b512616ca9fa24", "iat": 1615305159, "aud": "https://sp.example.com/caep", "txn": 8675309, "sub_id": { "format": "complex", "user": { "format": "iss_sub", "iss": "https://idp.example.com/123456789/", "sub": "jane.smith@example.com" }, "device": { "format": "iss_sub", "iss": "https://idp.example.com/123456789/", "sub": "e9297990-14d2-42ec-a4a9-4036db86509a" }, "tenant": { "format": "opaque", "id": "123456789" } }, "events": { "https://schemas.openid.net/secevent/caep/event-type/session-revoked": { "initiating_entity": "policy", "reason_admin": { "en": "Policy Violation: C076E822" }, "reason_user": { "en": "This device is no longer compliant.", "it": "Questo dispositivo non e piu conforme." }, "event_timestamp": 1615304991643 } } } Figure 5: Example: Session Revoked - Complex Subject describing user + device + tenant (includes optional claims) 3.2. Token Claims Change Event Type URI: https://schemas.openid.net/secevent/caep/event-type/token-claims- change Cappalli & Tulshibagwale Standards Track [Page 6] CAEP-Spec June 2024 Token Claims Change signals that a claim in a token, identified by the subject claim, has changed. The actual reason why the claims change occurred might be specified with the nested reason_admin and/or reason_user claims made in Section 2. 3.2.1. Event-Specific Claims claims REQUIRED, JSON object: one or more claims with their new value(s) When event_timestamp is included, its value MUST represent the time at which the claim value(s) changed. 3.2.2. Examples NOTE: The event type URI is wrapped, the backslash is the continuation character. { "iss": "https://idp.example.com/987654321/", "jti": "9afce1e4e642b165fcaacdd0e7aa4903", "iat": 1615305159, "aud": "https://sp.example2.net/caep", "txn": 8675309, "sub_id": { "format": "jwt_id", "iss": "https://idp.example.com/987654321/", "jti": "f61t6e20zdo3px56gepu8rzlsp4c1dpc0fx7" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/token-claims-change": { "event_timestamp": 1615304991643, "claims": { "role": "ro-admin" } } } } Figure 6: Example: OIDC ID Token Claims Change - Required claims only Cappalli & Tulshibagwale Standards Track [Page 7] CAEP-Spec June 2024 { "iss": "https://idp.example.com/987654321/", "jti": "9afce1e4e642b165fcaacdd0e7aa4903", "iat": 1615305159, "aud": "https://sp.example2.net/caep", "txn": 8675309, "sub_id": { "format": "jwt_id", "iss": "https://idp.example.com/987654321/", "jti": "f61t6e20zdo3px56gepu8rzlsp4c1dpc0fx7" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/token-claims-change": { "event_timestamp": 1615304991643, "initiating_entity": "policy", "reason_admin": { "en": "User left trusted network: CorpNet3" }, "reason_user": { "en": "You're no longer connected to a trusted network.", "it": "Non sei piu connesso a una rete attendibile." }, "claims": { "trusted_network": "false" } } } } Figure 7: Example: OIDC ID Token Claims Change - Optional claims Cappalli & Tulshibagwale Standards Track [Page 8] CAEP-Spec June 2024 { "iss": "https://idp.example.com/987654321/", "jti": "dae94fed5f459881efa38b65c6772ddc", "iat": 1615305159, "aud": "https://sp.example2.net/caep", "txn": 8675309, "sub_id": { "format": "saml_assertion_id", "issuer": "https://idp.example.com/987654321/", "assertion_id": "_a75adf55-01d7-dbd8372ebdfc" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/token-claims-change": { "event_timestamp": 1615304991643, "claims": { "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role": "ro-admin" } } } } Figure 8: Example: SAML Assertion Claims Change - Required claims only 3.3. Credential Change Event Type URI: https://schemas.openid.net/secevent/caep/event-type/credential-change The Credential Change event signals that a credential was created, changed, revoked or deleted. Credential Change scenarios include: * password/PIN change/reset * certificate enrollment, renewal, revocation and deletion * second factor / passwordless credential enrollment or deletion (U2F, FIDO2, OTP, app-based) The actual reason why the credential change occurred might be specified with the nested reason_admin and/or reason_user claims made in Section 2. 3.3.1. Event-Specific Claims credential_type REQUIRED, JSON string: This MUST be one of the Cappalli & Tulshibagwale Standards Track [Page 9] CAEP-Spec June 2024 following strings, or any other credential type supported mutually by the Transmitter and the Receiver. * password * pin * x509 * fido2-platform * fido2-roaming * fido-u2f * verifiable-credential * phone-voice * phone-sms * app change_type REQUIRED, JSON string: This MUST be one of the following strings: * create * revoke * update * delete friendly_name OPTIONAL, JSON string: credential friendly name x509_issuer OPTIONAL, JSON string: issuer of the X.509 certificate as defined in [RFC5280] x509_serial OPTIONAL, JSON string: serial number of the X.509 certificate as defined in [RFC5280] fido2_aaguid OPTIONAL, JSON string: FIDO2 Authenticator Attestation GUID as defined in [WebAuthn] When event_timestamp is included, its value MUST represent the time at which the credential change occurred. Cappalli & Tulshibagwale Standards Track [Page 10] CAEP-Spec June 2024 3.3.2. Examples NOTE: The event type URI is wrapped, the backslash is the continuation character. { "iss": "https://idp.example.com/3456789/", "jti": "07efd930f0977e4fcc1149a733ce7f78", "iat": 1615305159, "aud": "https://sp.example2.net/caep", "txn": 8675309, "sub_id": { "format": "iss_sub", "iss": "https://idp.example.com/3456789/", "sub": "jane.smith@example.com" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/credential-change": { "credential_type": "fido2-roaming", "change_type": "create", "fido2_aaguid": "accced6a-63f5-490a-9eea-e59bc1896cfc", "friendly_name": "Jane's USB authenticator", "initiating_entity": "user", "reason_admin": { "en": "User self-enrollment" }, "event_timestamp": 1615304991643 } } } Figure 9: Example: Provisioning a new FIDO2 authenticator - Simple Subject + optional claims 3.4. Assurance Level Change Event Type URI: https://schemas.openid.net/secevent/caep/event-type/assurance-level- change The Assurance Level Change event signals that there has been a change in authentication method since the initial user login. This change can be from a weak authentication method to a strong authentication method, or vice versa. Cappalli & Tulshibagwale Standards Track [Page 11] CAEP-Spec June 2024 In the first scenario, Assurance Level Change will an increase, while in the second scenario it will be a decrease. For example, a user can start a session with Service Provider A using single factor authentication (such as a password). The user can then open another session with Service Provider B using two-factor authentication (such as OTP). In this scenario an increase Assurance Level Change event will signal to Service Provider A that user has authenticated with a stronger authentication method. The actual reason why the assurance level changed might be specified with the nested reason_admin and/or reason_user claims made in Section 2. 3.4.1. Event-Specific Claims namespace: REQUIRED, JSON string: the namespace of the values in the current_level and previous_level claims. This string MAY be one of the following strings: * RFC8176: The assurance level values are from the [RFC8176] specification * RFC6711: The assurance level values are from the [RFC6711] specification * ISO-IEC-29115: The assurance level values are from the [ISO-IEC-29115] specification * NIST-IAL: The assurance level values are from the [NIST-IDPROOF] specification * NIST-AAL: The assurance level values are from the [NIST-AUTH] specification * NIST-FAL: The assurance level values are from the [NIST-FED] specification * Any other value that is an alias for a custom namespace agreed between the Transmitter and the Receiver current_level REQUIRED, JSON string: The current assurance level, as defined in the specified namespace previous_level OPTIONAL, JSON string: the previous assurance level, as defined in the specified namespace If the Transmitter omits this value, the Receiver MUST assume that the previous assurance level is unknown to the Transmitter Cappalli & Tulshibagwale Standards Track [Page 12] CAEP-Spec June 2024 change_direction OPTIONAL, JSON string: the assurance level increased or decreased If the Transmitter has specified the previous_level, then the Transmitter SHOULD provide a value for this claim. If present, this MUST be one of the following strings: * increase * decrease When event_timestamp is included, its value MUST represent the time at which the assurance level changed. 3.4.2. Examples { "iss": "https://idp.example.com/3456789/", "jti": "07efd930f0977e4fcc1149a733ce7f78", "iat": 1615305159, "aud": "https://sp.example2.net/caep", "txn": 8675309, "sub_id": { "format": "iss_sub", "iss": "https://idp.example.com/3456789/", "sub": "jane.smith@example.com" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/assurance-level-change": { "namespace": "NIST-AAL", "current_level": "nist-aal2", "previous_level": "nist-aal1", "change_direction": "increase", "initiating_entity": "user", "event_timestamp": 1615304991643 } } } Figure 10: Example: Assurance Level Increase - Simple Subject + optional claims Cappalli & Tulshibagwale Standards Track [Page 13] CAEP-Spec June 2024 { "iss": "https://idp.example.com/3456789/", "jti": "07efd930f0977e4fcc1149a733ce7f78", "iat": 1615305159, "aud": "https://sp.example2.net/caep", "txn": 8675309, "sub_id": { "format": "iss_sub", "iss": "https://idp.example.com/3456789/", "sub": "jane.smith@example.com" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/assurance-level-change": { "namespace": "Retinal Scan", "current_level": "hi-res-scan", "initiating_entity": "user", "event_timestamp": 1615304991643 } } } Figure 11: Example: Custom Assurance Level - Simple Subject 3.5. Device Compliance Change Event Type URI: https://schemas.openid.net/secevent/caep/event-type/device- compliance-change Device Compliance Change signals that a device's compliance status has changed. The actual reason why the status change occurred might be specified with the nested reason_admin and/or reason_user claims made in Section 2. 3.5.1. Event-Specific Claims previous_status REQUIRED, JSON string: the compliance status prior to the change that triggered the event This MUST be one of the following strings: * compliant * not-compliant Cappalli & Tulshibagwale Standards Track [Page 14] CAEP-Spec June 2024 current_status REQUIRED, JSON string: the current status that triggered the event This MUST be one of the following strings: * compliant * not-compliant When event_timestamp is included, its value MUST represent the time at which the device compliance status changed. 3.5.2. Examples NOTE: The event type URI is wrapped, the backslash is the continuation character. Cappalli & Tulshibagwale Standards Track [Page 15] CAEP-Spec June 2024 { "iss": "https://idp.example.com/123456789/", "jti": "24c63fb56e5a2d77a6b512616ca9fa24", "iat": 1615305159, "aud": "https://sp.example.com/caep", "txn": 8675309, "sub_id": { "format": "complex", "device": { "format": "iss_sub", "iss": "https://idp.example.com/123456789/", "sub": "e9297990-14d2-42ec-a4a9-4036db86509a" }, "tenant": { "format": "opaque", "id": "123456789" } }, "events": { "https://schemas.openid.net/secevent/caep/event-type/device-compliance-change": { "current_status": "not-compliant", "previous_status": "compliant", "initiating_entity": "policy", "reason_admin": { "en": "Location Policy Violation: C076E8A3" }, "reason_user": { "en": "Device is no longer in a trusted location." }, "event_timestamp": 1615304991643 } } } Figure 12: Example: Device No Longer Compliant - Complex Subject + optional claims 3.6. Session Established Event Type URI: https://schemas.openid.net/secevent/caep/event-type/session- established The Session Established event signifies that the Transmitter has established a new session for the subject. Receivers may use this information for a number of reasons, including: Cappalli & Tulshibagwale Standards Track [Page 16] CAEP-Spec June 2024 * A service acting as a Transmitter can close the loop with the IdP after a user has been federated from the IdP * An IdP can detect unintended logins * A Receiver can establish an inventory of user sessions The event_timestamp in this event type specifies the time at which the session was established. 3.6.1. Event Specific Claims The following optional claims MAY be included in the Session Established event: ips The array of IP addresses of the user as observed by the Transmitter. The value MUST be in the format of an array of strings, each one of which represents the RFC 4001 [RFC4001] string represetation of an IP address. (*NOTE*, this can be different from the one observed by the Receiver for the same user because of network translation) fp_ua Fingerprint of the user agent computed by the Transmitter. (*NOTE*, this is not to identify the session, but to present some qualities of the session) acr The authentication context class reference of the session, as established by the Transmitter. The value of this field MUST be interpreted in the same way as the corresponding field in an OpenID Connect ID Token [OpenID.Core] amr The authentication methods reference of the session, as established by the Transmitter. The value of this field MUST be an array of strings, each of which MUST be interpreted in the same way as the corresponding field in an OpenID Connect ID Token [OpenID.Core] ext_id The external session identifier, which may be used to correlate this session with a broader session (e.g., a federated session established using SAML) 3.6.2. Examples The following is a non-normative example of the session-established event type: Cappalli & Tulshibagwale Standards Track [Page 17] CAEP-Spec June 2024 { "iss": "https://idp.example.com/123456789/", "jti": "24c63fb56e5a2d77a6b512616ca9fa24", "iat": 1615305159, "aud": "https://sp.example.com/caep", "txn": 8675309, "sub_id": { "format": "email", "email": "someuser@somedomain.com" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/session-established": { "ips": ["192.168.1.12", "10.1.1.1"], "fp_ua": "abb0b6e7da81a42233f8f2b1a8ddb1b9a4c81611", "acr": "AAL2", "amr": "otp", "event_timestamp": 1615304991643 } } } 3.7. Session Presented Event Type URI: https://schemas.openid.net/secevent/caep/event-type/session-presented The Session Presented event signifies that the Transmitter has observed the session to be present at the Transmitter at the time indicated by the event_timestamp field in the Session Presented event. Receivers may use this information for reasons that include: * Detecting abnormal user activity * Establishing an inventory of live sessions belonging to a user 3.7.1. Event Specific Claims The following optional claims MAY be present in a Session Presented event: ips The array of IP addresses of the user as observed by the Transmitter. The value MUST be in the format of an array of strings, each one of which represents the RFC 4001 [RFC4001] string represetation of an IP address. (*NOTE*, this can be different from the one observed by the Receiver for the same user because of network translation) Cappalli & Tulshibagwale Standards Track [Page 18] CAEP-Spec June 2024 fp_ua Fingerprint of the user agent computed by the Transmitter. (*NOTE*, this is not to identify the session, but to present some qualities of the session) ext_id The external session identifier, which may be used to correlate this session with a broader session (e.g., a federated session established using SAML) 3.7.2. Examples The following is a non-normative example of a Session Presented event: { "iss": "https://idp.example.com/123456789/", "jti": "24c63fb56e5a2d77a6b512616ca9fa24", "iat": 1615305159, "aud": "https://sp.example.com/caep", "txn": 8675309, "sub_id": { "format": "email", "email": "someuser@somedomain.com" }, "events": { "https://schemas.openid.net/secevent/caep/event-type/session-presented": { "ips": ["192.168.1.12","10.1.1.1"], "fp_ua": "abb0b6e7da81a42233f8f2b1a8ddb1b9a4c81611", "ext_id": "12345", "event_timestamp": 1615304991643 } }} 4. Security Considerations Any implementations of events described in this document SHOULD comply with the Shared Signals Framework [SSF]. Exchanging events described herein without complying with the Shared Signals Framework [SSF] may result in security issues. 5. Normative References [ISO-IEC-29115] Standardization, I. O. for., "ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework", March 2013, . Cappalli & Tulshibagwale Standards Track [Page 19] CAEP-Spec June 2024 [NIST-AUTH] Grassi, P., Garcia, M., and J. Fenton, "Digital Identity Guidelines, Authentication and Lifecycle Management", June 2017, . [NIST-FED] Grassi, P. A., Richer, J. P., Squire, S. K., Fenton, J. L., and E. M. Nadeau, "Digital Identity Guidelines, Federation and Assertions", n.d., . [NIST-IDPROOF] Grassi, P. A. and J. L. Fenton, "Digital Identity Guidelines, Enrollment and Identity Proofing", June 2017, . [OpenID.Core] Sakimura, N., Bradley, J., Jones, M. B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 - ID Token", November 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6711] Johansson, L., "An IANA Registry for Level of Assurance (LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August 2012, . Cappalli & Tulshibagwale Standards Track [Page 20] CAEP-Spec June 2024 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8176] Jones, M., Hunt, P., and A. Nadalin, "Authentication Method Reference Values", RFC 8176, DOI 10.17487/RFC8176, June 2017, . [SSF] Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman, A., and John Bradley, "OpenID Shared Signals and Events Framework Specification 1.0", May 2021, . [WebAuthn] Balfanz, D., "Web Authentication: An API for accessing Public Key Credentials Level 2", 8 April 2021, . Appendix A. Acknowledgements The authors wish to thank all members of the OpenID Foundation Shared Signals Working Group who contributed to the development of this specification. Appendix B. Notices Copyright (c) 2024 The OpenID Foundation. The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF. The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make Cappalli & Tulshibagwale Standards Track [Page 21] CAEP-Spec June 2024 no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non- infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification. Appendix C. Document History [[ To be removed from the final specification ]] -03 * New "Session Established" and "Session Presented" event types * Added namespace required field to Assurance Level Change event * Changed the name referencing SSE to SSF * Added format to the subjects in examples in CAEP * Formatting and typo changes Authors' Addresses Tim Cappalli Microsoft Email: tim.cappalli@microsoft.com Atul Tulshibagwale SGNL Email: atul@sgnl.ai Cappalli & Tulshibagwale Standards Track [Page 22]