Subject: [Id-event] SAML subject identifier type

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 09:17:32 -0700

Hi all,
Based on the discussions in the SSE working group within the OpenID
Foundation, we would like to propose that the subject identifier
specification include a SAML subject identifier type. This is so that
sessions established across peers using SAML may be identified in events
that include the subject identifier.

 A SAML subject identifier has only one claim within it, the assertion id
of the SAML assertion used to establish the single sign-on session.

This change is also included in my proposal here
<https://github.com/richanna/secevent/pull/1>.

Thanks,
Atul

---

From: Chris Phillips <[email-masked]>
Date: Mon, 13 Jul 2020 17:29:51 +0000

Hi.

Quiet lurker observing..

Thanks for consider the SAML elements.. 

Atul, are you referring to the actual session identifier that someone may have where the Subject-Id was exchanged OR the actual Subject-id itself in your reference in the proposal with the github link?

I’m trying to square what I see on the git delta on line 294-296 in https://github.com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994

And a Subject-id as shown in the example in 3.3.3 here: https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.html#_Toc536097229

What you offered in the example is not a Subject-id  per the OASIS SAML spec as written in section 3.3.1

Am I mis-interpreting something?

C

From: Id-event <[email-masked]> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]>
Date: Monday, July 13, 2020 at 12:17 PM
To: "[email-masked]" <[email-masked]>
Subject: [Id-event] SAML subject identifier type

Hi all,

Based on the discussions in the SSE working group within the OpenID Foundation, we would like to propose that the subject identifier specification include a SAML subject identifier type. This is so that sessions established across peers using SAML may be identified in events that include the subject identifier.

 A SAML subject identifier has only one claim within it, the assertion id of the SAML assertion used to establish the single sign-on session.

This change is also included in my proposal here.

Thanks,

Atul

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 13:22:03 -0700

Hi Chris,
I was proposing using the "assertion id" (SAML Core
<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf> spec,
line 553) in the proposal, not the "subject-id" as defined in SAML (spec
section 3.3). The main reason was to be able to refer to a session that was
established using a specific assertion. If it's useful, we could perhaps
extend the SAML subject identifier type in this spec to include either the
assertion_id or the subject_id claim.

Thanks,
Atul

On Mon, Jul 13, 2020 at 10:30 AM Chris Phillips <[email-masked]>
wrote:

> Atul, are you referring to the actual session identifier that someone may
> have where the Subject-Id was exchanged OR the actual Subject-id itself in
> your reference in the proposal with the github link?
>
>
>
> I’m trying to square what I see on the git delta on line 294-296 in
> https://github.com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994
>
>
>
>
>
> And a Subject-id as shown in the example in 3.3.3 here:
> https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.html#_Toc536097229
>
>
>
> *From: *Id-event <[email-masked]> on behalf of Atul
> Tulshibagwale <atultulshi=[email-masked]>
> *Date: *Monday, July 13, 2020 at 12:17 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Id-event] SAML subject identifier type
>
>
>
> Hi all,
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 14:12:14 -0700

Just clarifying the proposal as it stands today (before incorporating
Chris's input):
The following section should be added in the "Subject Identifier Types"
section:
4.9.  SAML Subject Identifier Type

   The SAML [SAML.REF] Subject Identifier Type describes a subject by
   the assertion identifier in the SAML assertion that was used to
   convey the subject's information to the Receiver.  Subject
   Identifiers of this type MUST contain an ` assertion_id"claim.  The
   value of this claim is a string that is equal to the Assertion
   Identifier in the SAML assertion.  The SAML Subject Identifier Type
   is identified by the name "saml`.

   Below is a non-normative example Subject Identifier for the SAML
   Subject Identifier Type:

   {
     "subject_type": "saml",
     "assertion_id": "_f551d88963ab4e3decb7cfe8f4dcc3f5",
   }

     Figure 8: Example: Subject Identifier for SAML Subject Identifier
                                   Type.

On Mon, Jul 13, 2020 at 1:22 PM Atul Tulshibagwale <[email-masked]>
wrote:

> <http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>
> spec, line 553) in the proposal, not the "subject-id" as defined in SAML
> (spec section 3.3). The main reason was to be able to refer to a session
> that was established using a specific assertion. If it's useful, we could
> perhaps extend the SAML subject identifier type in this spec to include
> either the assertion_id or the subject_id claim.
>
> Thanks,
> Atul
>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 14 Jul 2020 22:31:56 +0300

I need a lot more context here. So far, subject IDs have denoted durable entities, such as email addresses, phone numbers, account. This is adding a subject ID that denotes an ephemeral entity, basically similar to a session ID. This looks weird from an architectural point of view, and also begs the question, why specifically SAML and not other session types.

Thanks,

                Yaron 

From: Id-event <[email-masked]> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]>
Date: Tuesday, July 14, 2020 at 00:14
To: Chris Phillips <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Id-event] SAML subject identifier type

Just clarifying the proposal as it stands today (before incorporating Chris's input):

The following section should be added in the "Subject Identifier Types" section:

   {
     "subject_type": "saml",

 

On Mon, Jul 13, 2020 at 1:22 PM Atul Tulshibagwale <[email-masked]> wrote:

Hi Chris,

I was proposing using the "assertion id" (SAML Core spec, line 553) in the proposal, not the "subject-id" as defined in SAML (spec section 3.3). The main reason was to be able to refer to a session that was established using a specific assertion. If it's useful, we could perhaps extend the SAML subject identifier type in this spec to include either the assertion_id or the subject_id claim.

Thanks,

Atul

On Mon, Jul 13, 2020 at 10:30 AM Chris Phillips <[email-masked]> wrote:

Hi.

Quiet lurker observing..

 

C

Hi all,

Thanks,

Atul

_______________________________________________ Id-event mailing list [email-masked] https://www.ietf.org/mailman/listinfo/id-event

---

From: Atul Tulshibagwale <[email-masked]>
Date: Tue, 14 Jul 2020 13:26:23 -0700

Hi Yaron,
There are a few SSE use cases where the events are about a specific single
sign-on session. You're right that this should not be limited to SAML. The
RISC profile of SETs (based on which we are doing the SSE work) had the ID
Token subject identifier type, which for some reason is missing in this
spec (I did not realize until now). The specific events that need to refer
to sessions are:

   - Identity provider context change: The conditions under which a SAML
   assertion or OIDC token was generated are no longer valid. This can be due
   to various things, including a password change.
   - Session property change: A session has been determined to have been
   compromised
   - Revocation: The issuer of the single sign-on SAML assertion or ID
   Token needs to be revoke

I can also add the ID Token claim from the RISC profile
<https://bitbucket.org/openid/risc/src/master/openid-risc-profile-1_0.txt#lines-250>
to my pull request.

Thanks,
Atul

On Tue, Jul 14, 2020 at 12:32 PM Yaron Sheffer <[email-masked]>
wrote:

> I need a lot more context here. So far, subject IDs have denoted durable
> entities, such as email addresses, phone numbers, account. This is adding a
> subject ID that denotes an ephemeral entity, basically similar to a session
> ID. This looks weird from an architectural point of view, and also begs the
> question, why specifically SAML and not other session types.
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> *Date: *Tuesday, July 14, 2020 at 00:14
> *To: *Chris Phillips <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Id-event] SAML subject identifier type
>
>
>
> https://github..com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994
> <https://github.com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994>
>
>
>
>
>
> <https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01..html#_Toc536097229>
>
>
>
> _______________________________________________ Id-event mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 15 Jul 2020 01:01:31 +0300

Hi Atul,

The ID Token subject type, as described in the document you are referencing, does not add any semantics, compared to a “phone number” or “email” subject type. So I don’t see the value in adding it.

In addition, it does not, actually, describe an ID Token. In fact the text is very clear that it describes a “subject” (a durable entity) rather than a session, and does it by citing various claims included in the ID token. So as a subject identifier type, it is not at all equivalent to a SAML assertion.

As to the SAML Assertion subject type, I think these use cases could be addressed by adding information to the event.

Thanks,

                Yaron

From: Atul Tulshibagwale <[email-masked]>
Date: Tuesday, July 14, 2020 at 23:26
To: Yaron Sheffer <[email-masked]>
Cc: Chris Phillips <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Id-event] SAML subject identifier type

Hi Yaron,

There are a few SSE use cases where the events are about a specific single sign-on session. You're right that this should not be limited to SAML. The RISC profile of SETs (based on which we are doing the SSE work) had the ID Token subject identifier type, which for some reason is missing in this spec (I did not realize until now). The specific events that need to refer to sessions are:

Identity provider context change: The conditions under which a SAML assertion or OIDC token was generated are no longer valid. This can be due to various things, including a password change.
Session property change: A session has been determined to have been compromised
Revocation: The issuer of the single sign-on SAML assertion or ID Token needs to be revoke
I can also add the ID Token claim from the RISC profile to my pull request.

Thanks,

Atul

On Tue, Jul 14, 2020 at 12:32 PM Yaron Sheffer <[email-masked]> wrote:

Thanks,

                Yaron 

   {
     "subject_type": "saml",

 

Hi Chris,

Thanks,

Atul

Hi.

Quiet lurker observing..

I’m trying to square what I see on the git delta on line 294-296 in https://github..com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994

C

Hi all,

Thanks,

Atul

---

From: Brian Campbell <[email-masked]>
Date: Tue, 14 Jul 2020 17:08:34 -0600

+ 1 to what Yaron is saying here. I'd include also the "iss-sub" subject
identifier type
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-05#section-3.4
as already having semantics covering what's described in the ID Token
Claims Subject Identifier Type in the RISC document referenced. And all
those things represent a durable subject rather than a session, which
strikes me as appropriate for a document that describes identifying
subjects. A SAML assertion ID, however, which is an identifier of an XML
document that is only indirectly related to a session by an association
that likely isn't maintained, does not seem appropriate as a "subject
identifier".

On Tue, Jul 14, 2020 at 4:01 PM Yaron Sheffer <[email-masked]> wrote:

> Hi Atul,
>
>
>
> The ID Token subject type, as described in the document you are
> referencing, does not add any semantics, compared to a “phone number” or
> “email” subject type. So I don’t see the value in adding it.
>
>
>
> In addition, it does not, actually, describe an ID Token. In fact the text
> is very clear that it describes a “subject” (a durable entity) rather than
> a session, and does it by citing various claims included in the ID token.
> So as a subject identifier type, it is not at all equivalent to a SAML
> assertion.
>
>
>
> As to the SAML Assertion subject type, I think these use cases could be
> addressed by adding information to the event.
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> *From: *Atul Tulshibagwale <[email-masked]>
> *Date: *Tuesday, July 14, 2020 at 23:26
> *To: *Yaron Sheffer <[email-masked]>
> *Cc: *Chris Phillips <[email-masked]>, "[email-masked]" <
> [email-masked]>
> <https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1..0-cs01..html#_Toc536097229>
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Atul Tulshibagwale <[email-masked]>
Date: Tue, 14 Jul 2020 16:30:54 -0700

IMO if we have a common enough use-case that requires a specific type to be
defined, then we should define that type in the spec rather than rely on an
interpretation of the "iss-sub" type, since that interpretation can cause
incompatibilities.

In this specific case however I feel that the use cases outlined in my
previous email can be achieved (with limitations) using the durable subject
types such as email. I'd like the members of the SSE working group to chime
in (since that is where this got added), or we can drop the SAML subject
identifier type.

On Tue, Jul 14, 2020 at 4:09 PM Brian Campbell <[email-masked]>
wrote:

>> In addition, it does not, actually, describe an ID Token. In fact the
>> text is very clear that it describes a “subject” (a durable entity) rather
>> than a session, and does it by citing various claims included in the ID
>> token. So as a subject identifier type, it is not at all equivalent to a
>> SAML assertion.
>>
>>
>>
>> There are a few SSE use cases where the events are about a specific
>> single sign-on session. You're right that this should not be limited to
>> SAML. The RISC profile of SETs (based on which we are doing the SSE work)
>> had the ID Token subject identifier type, which for some reason is missing
>> in this spec (I did not realize until now). The specific events that need
>> to refer to sessions are:
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: Atul Tulshibagwale <[email-masked]>
Date: Tue, 14 Jul 2020 16:31:40 -0700

+Openid-specs-risc <[email-masked]>

On Tue, Jul 14, 2020 at 4:30 PM Atul Tulshibagwale <[email-masked]>
wrote:

> IMO if we have a common enough use-case that requires a specific type to
> be defined, then we should define that type in the spec rather than rely on
> an interpretation of the "iss-sub" type, since that interpretation can
> cause incompatibilities.
>
>>>    - Identity provider context change: The conditions under which a
>>>    SAML assertion or OIDC token was generated are no longer valid. This can be
>>>    due to various things, including a password change.
>>>    - Session property change: A session has been determined to have
>>>    been compromised
>>> Atul, are you referring to the actual session identifier that someone
>>> may have where the Subject-Id was exchanged OR the actual Subject-id itself
>>> in your reference in the proposal with the github link?
>>>
>>>
>>>
>>>  A SAML subject identifier has only one claim within it, the assertion
>>> id of the SAML assertion used to establish the single sign-on session.
>>>
>>>
>>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 14 Jul 2020 23:53:52 +0000

The RISC Profile’s “ID Token Claims” type does not identify a subject that is an ID Token, it identifies a subject that was the subject of an ID Token. It was intended for cases where the OP sent multiple identifiers of different types in the ID Token (e.g., iss+sub and email), and does not know which of them the client will recognize (yes, the should use iss+sub; no, they doesn’t always do so). This type was replaced in draft-ietf-secevent-subject-identifiers-03 with the “aliases” type, which is a general solution to this problem that is not defined in terms of one particular use case (i.e., ID Tokens).

The OIDF SSE working group’s OAuth Event Types draft<https://openid.net/specs/oauth-event-types-1_0-ID1.html#rfc.section.2.1> defines a “oauth_token” type that identifies a subject that is an OAuth 2.0 token, and does so using either the full or partial plain text value of the token, or a hash of the token.

It is perfectly fine for a token to be the subject of a security event. 8417<https://www.rfc-editor.org/rfc/rfc8417.html#section-2.2> actually includes the following as an example of a possible value for the “sub” claim:
*  a token identifier (e.g. "jti") for a revoked token.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

From: Id-event <[email-masked]> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]>
Date: Tuesday, July 14, 2020 at 4:32 PM
To: Brian Campbell <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Chris Phillips <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [EXTERNAL] [Id-event] SAML subject identifier type

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

IMO if we have a common enough use-case that requires a specific type to be defined, then we should define that type in the spec rather than rely on an interpretation of the "iss-sub" type, since that interpretation can cause incompatibilities.

In this specific case however I feel that the use cases outlined in my previous email can be achieved (with limitations) using the durable subject types such as email. I'd like the members of the SSE working group to chime in (since that is where this got added), or we can drop the SAML subject identifier type.

On Tue, Jul 14, 2020 at 4:09 PM Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
+ 1 to what Yaron is saying here. I'd include also the "iss-sub" subject identifier type https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-05#section-3.4 as already having semantics covering what's described in the ID Token Claims Subject Identifier Type in the RISC document referenced. And all those things represent a durable subject rather than a session, which strikes me as appropriate for a document that describes identifying subjects. A SAML assertion ID, however, which is an identifier of an XML document that is only indirectly related to a session by an association that likely isn't maintained, does not seem appropriate as a "subject identifier".

On Tue, Jul 14, 2020 at 4:01 PM Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
Hi Atul,

Thanks,
                Yaron

From: Atul Tulshibagwale <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 14, 2020 at 23:26
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Cc: Chris Phillips <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] SAML subject identifier type

Hi Yaron,
There are a few SSE use cases where the events are about a specific single sign-on session. You're right that this should not be limited to SAML. The RISC profile of SETs (based on which we are doing the SSE work) had the ID Token subject identifier type, which for some reason is missing in this spec (I did not realize until now). The specific events that need to refer to sessions are:
·         Identity provider context change: The conditions under which a SAML assertion or OIDC token was generated are no longer valid. This can be due to various things, including a password change.
·         Session property change: A session has been determined to have been compromised
·         Revocation: The issuer of the single sign-on SAML assertion or ID Token needs to be revoke
I can also add the ID Token claim from the RISC profile<https://bitbucket.org/openid/risc/src/master/openid-risc-profile-1_0.txt#lines-250> to my pull request.

Thanks,
Atul

On Tue, Jul 14, 2020 at 12:32 PM Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
I need a lot more context here. So far, subject IDs have denoted durable entities, such as email addresses, phone numbers, account. This is adding a subject ID that denotes an ephemeral entity, basically similar to a session ID. This looks weird from an architectural point of view, and also begs the question, why specifically SAML and not other session types.

Thanks,
                Yaron

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]<mailto:[email-masked]..org>>
Date: Tuesday, July 14, 2020 at 00:14
To: Chris Phillips <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] SAML subject identifier type

   {
     "subject_type": "saml",

On Mon, Jul 13, 2020 at 1:22 PM Atul Tulshibagwale <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chris,
I was proposing using the "assertion id" (SAML Core<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf> spec, line 553) in the proposal, not the "subject-id" as defined in SAML (spec section 3.3). The main reason was to be able to refer to a session that was established using a specific assertion. If it's useful, we could perhaps extend the SAML subject identifier type in this spec to include either the assertion_id or the subject_id claim.

Thanks,
Atul

On Mon, Jul 13, 2020 at 10:30 AM Chris Phillips <[email-masked]<mailto:[email-masked]>> wrote:
Hi.
Quiet lurker observing..
Thanks for consider the SAML elements..

I’m trying to square what I see on the git delta on line 294-296 in https://github...com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994<https://github.com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994>

And a Subject-id as shown in the example in 3.3.3 here: https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.html#_Toc536097229<https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1..0-cs01..html#_Toc536097229>

C

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]<mailto:[email-masked]>>
Date: Monday, July 13, 2020 at 12:17 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] SAML subject identifier type

Hi all,

This change is also included in my proposal here<https://github.com/richanna/secevent/pull/1>.

Thanks,
Atul

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________ Id-event mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Atul Tulshibagwale <[email-masked]>
Date: Wed, 15 Jul 2020 12:46:03 -0700

How do we propose to support the two subject types defined in the OAuth
Event Types <https://openid.net/specs/oauth-event-types-1_0-ID1.html> spec
here?

On Tue, Jul 14, 2020 at 4:54 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> The RISC Profile’s “ID Token Claims” type does not identify a subject that
> is an ID Token, it identifies a subject that was the subject of an ID
> Token. It was intended for cases where the OP sent multiple identifiers of
> different types in the ID Token (e.g., iss+sub and email), and does not
> know which of them the client will recognize (yes, the *should* use
> iss+sub; no, they doesn’t always do so). This type was replaced in
> draft-ietf-secevent-subject-identifiers-03 with the “aliases” type, which
> is a general solution to this problem that is not defined in terms of one
> particular use case (i.e., ID Tokens).
>
>
>
> The OIDF SSE working group’s OAuth Event Types draft
> <https://openid.net/specs/oauth-event-types-1_0-ID1.html#rfc.section.2.1>
> defines a “oauth_token” type that identifies a subject that is an OAuth 2.0
> token, and does so using either the full or partial plain text value of the
> token, or a hash of the token.
>
>
>
> It is perfectly fine for a token to be the subject of a security event.
> 8417 <https://www.rfc-editor.org/rfc/rfc8417.html#section-2.2> actually
> includes the following as an example of a possible value for the “sub”
> claim:
>
> *Date: *Tuesday, July 14, 2020 at 4:32 PM
> *To: *Brian Campbell <[email-masked]>
> *Cc: *Yaron Sheffer <[email-masked]>, Chris Phillips <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: [EXTERNAL] [Id-event] SAML subject identifier type
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> ·         Identity provider context change: The conditions under which a
> Tulshibagwale <atultulshi=[email-masked]
> <[email-masked]..org>>
> https://github...com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994
> review, use, distribution or disclosure by others is strictly prohibited..

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 15 Jul 2020 21:24:55 +0000

I think the two subject types – the “oauth_token” type described in my prior email, and a “oauth_client” type that identifies a subject by its OAuth 2.0 client ID – are reasonable types to define. I don’t see a particular need to move them into the base spec – we define an IANA registry precisely so we don’t have to try to define everything up front – but I’m not opposed to the idea.

I’m not sure where this notion of a “durable subject” came from. Right in the introduction, RFC 8417<https://www.rfc-editor.org/rfc/rfc8417.html#section-1> says the subject of a security event “may be permanent (e.g., a user account) or temporary (e.g., an HTTP session) in nature.” There are plenty of use cases for events where the subjects are temporary/ephemeral:

  1.  Session termination
  2.  Changes in the security posture for a session
  3.  Token revocation
  4.  Asynchronous approval of a request
  5.  Changes in the state of a transaction
…etc.

Whether or not it makes sense to identify a session subject using a SAML assertion ID (or an ID Token “jti” claim, in the OIDC world) is a separate question. Adding semantics to existing identifiers tends to lead to lots of unforeseen complications, and depend on assumptions that don’t always hold true. In this case, there seems to be an assumption that there is a 1:1 relationship between a SAML assertion and a session. This is not always the case.

Regardless, a SAML assertion ID is clearly an appropriate identifier when the subject is a SAML assertion. I don’t know offhand if there are any use cases for events relating to a SAML assertion itself. I can certainly see use cases for events related to JWTs (e.g., revocation of a JWT access token), where a “jti” subject identifier type would be appropriate. I’m inclined to add it to the draft, if for no other reason than to provide a normative demonstration of a subject identifier that would be used to identify a more ephemeral subject.

–

From: Id-event <[email-masked]> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]>
Date: Wednesday, July 15, 2020 at 12:47 PM
To: "Richard Backman, Annabelle" <richanna=[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Brian Campbell <[email-masked]>, Chris Phillips <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [EXTERNAL] [Id-event] SAML subject identifier type

How do we propose to support the two subject types defined in the OAuth Event Types<https://openid.net/specs/oauth-event-types-1_0-ID1.html> spec here?

On Tue, Jul 14, 2020 at 4:54 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
The RISC Profile’s “ID Token Claims” type does not identify a subject that is an ID Token, it identifies a subject that was the subject of an ID Token. It was intended for cases where the OP sent multiple identifiers of different types in the ID Token (e.g., iss+sub and email), and does not know which of them the client will recognize (yes, the should use iss+sub; no, they doesn’t always do so). This type was replaced in draft-ietf-secevent-subject-identifiers-03 with the “aliases” type, which is a general solution to this problem that is not defined in terms of one particular use case (i.e., ID Tokens).

The OIDF SSE working group’s OAuth Event Types draft<https://openid.net/specs/oauth-event-types-1_0-ID1.html#rfc.section.2.1> defines a “oauth_token” type that identifies a subject that is an OAuth 2.0 token, and does so using either the full or partial plain text value of the token, or a hash of the token..

–

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 14, 2020 at 4:32 PM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Chris Phillips <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [EXTERNAL] [Id-event] SAML subject identifier type

Thanks,
                Yaron

Hi Yaron,
There are a few SSE use cases where the events are about a specific single sign-on session. You're right that this should not be limited to SAML. The RISC profile of SETs (based on which we are doing the SSE work) had the ID Token subject identifier type, which for some reason is missing in this spec (I did not realize until now). The specific events that need to refer to sessions are:
•         Identity provider context change: The conditions under which a SAML assertion or OIDC token was generated are no longer valid. This can be due to various things, including a password change.
•         Session property change: A session has been determined to have been compromised
•         Revocation: The issuer of the single sign-on SAML assertion or ID Token needs to be revoke
I can also add the ID Token claim from the RISC profile<https://bitbucket.org/openid/risc/src/master/openid-risc-profile-1_0.txt#lines-250> to my pull request.

Thanks,
Atul

On Tue, Jul 14, 2020 at 12:32 PM Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
I need a lot more context here. So far, subject IDs have denoted durable entities, such as email addresses, phone numbers, account. This is adding a subject ID that denotes an ephemeral entity, basically similar to a session ID. This looks weird from an architectural point of view, and also begs the question, why specifically SAML and not other session types.

Thanks,
                Yaron

   {
     "subject_type": "saml",

Thanks,
Atul

On Mon, Jul 13, 2020 at 10:30 AM Chris Phillips <[email-masked]<mailto:[email-masked]>> wrote:
Hi.
Quiet lurker observing..
Thanks for consider the SAML elements..

C

Hi all,

Thanks,
Atul

---

From: Mike Jones <[email-masked]>
Date: Wed, 15 Jul 2020 22:20:45 +0000

I’d suggest not defining any subject types that we don’t have immediate use cases for, as we might get the details wrong.  We’re creating a registry to add new ones, so they can always be added later when they’re actually needed.

Let’s keep this simple, while meeting the immediately known needs.

                                                       -- Mike

From: Id-event <[email-masked]> On Behalf Of Richard Backman, Annabelle
Sent: Wednesday, July 15, 2020 2:25 PM
To: Atul Tulshibagwale <atultulshi=[email-masked]>; Richard Backman, Annabelle <richanna=[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Brian Campbell <[email-masked]>; Chris Phillips <[email-masked]>; [email-masked]
Subject: Re: [Id-event] SAML subject identifier type

  1.  Session termination

–

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]<mailto:atultulshi=[email-masked]>>
Date: Wednesday, July 15, 2020 at 12:47 PM
To: "Richard Backman, Annabelle" <richanna=[email-masked]<mailto:richanna=[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Brian Campbell <[email-masked]<mailto:[email-masked]>>, Chris Phillips <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [EXTERNAL] [Id-event] SAML subject identifier type

–

Thanks,
                Yaron

Hi Yaron,

Thanks,
Atul

Thanks,
                Yaron

   {
     "subject_type": "saml",

Thanks,
Atul

C

Hi all,

Thanks,
Atul

---

From: Dick Hardt <[email-masked]>
Date: Wed, 15 Jul 2020 15:22:03 -0700

+1

On Wed, Jul 15, 2020 at 3:21 PM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> I’d suggest not defining any subject types that we don’t have immediate
> use cases for, as we might get the details wrong.  We’re creating a
> registry to add new ones, so they can always be added later when they’re
> actually needed.
>
>
>
> *From:* Id-event <[email-masked]> *On Behalf Of *Richard
> Backman, Annabelle
> *Sent:* Wednesday, July 15, 2020 2:25 PM
> *To:* Atul Tulshibagwale <atultulshi=[email-masked]>;
> Richard Backman, Annabelle <richanna=[email-masked]>
> *Cc:* Yaron Sheffer <[email-masked]>; Brian Campbell <
> [email-masked]>; Chris Phillips <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Id-event] SAML subject identifier type
>
>
>
> I think the two subject types – the “oauth_token” type described in my
> prior email, and a “oauth_client” type that identifies a subject by its
> OAuth 2.0 client ID – are reasonable types to define. I don’t see a
> particular need to move them into the base spec – we define an IANA
> registry precisely so we don’t have to try to define everything up front –
> but I’m not opposed to the idea.
>
>
>
> I’m not sure where this notion of a “durable subject” came from. Right in
> the introduction, RFC 8417
> <https://www.rfc-editor.org/rfc/rfc8417.html#section-1> says the subject
> of a security event “may be permanent (e.g., a user account) or temporary
> (e.g., an HTTP session) in nature.” There are plenty of use cases for
> events where the subjects are temporary/ephemeral:
>
>    1. Session termination
> Whether or not it makes sense to identify a session subject using a SAML
> assertion ID (or an ID Token “jti” claim, in the OIDC world) is a separate
> question. Adding semantics to existing identifiers tends to lead to lots of
> unforeseen complications, and depend on assumptions that don’t always hold
> true. In this case, there seems to be an assumption that there is a 1:1
> relationship between a SAML assertion and a session. This is not always the
> case.
>
>
>
> Regardless, a SAML assertion ID is clearly an appropriate identifier when
> the subject is a SAML assertion. I don’t know offhand if there are any use
> cases for events relating to a SAML assertion itself. I can certainly see
> use cases for events related to JWTs (e.g., revocation of a JWT access
> token), where a “jti” subject identifier type would be appropriate. I’m
> inclined to add it to the draft, if for no other reason than to provide a
> normative demonstration of a subject identifier that would be used to
> identify a more ephemeral subject.
>
>
>
> –
>
> *https://aws.amazon.com/identity/ <https://aws.amazon.com/identity/>*
>
>
>
>
>
> *Date: *Wednesday, July 15, 2020 at 12:47 PM
> *To: *"Richard Backman, Annabelle" <richanna=[email-masked]>
> *Cc: *Yaron Sheffer <[email-masked]>, Brian Campbell <
> [email-masked]>, Chris Phillips <[email-masked]>, "
> [email-masked]" <[email-masked]>
> Event Types <https://openid.net/specs/oauth-event-types-1_0-ID1.html>
> spec here?
>
>
>
> token, or a hash of the token..
>
>
>
> On Tue, Jul 14, 2020 at 12:32 PM Yaron Sheffer <[email-masked]
> <[email-masked]>> wrote:
>
> On Mon, Jul 13, 2020 at 10:30 AM Chris Phillips <[email-masked]
> <[email-masked]>> wrote:
>
> Hi.
>
> Quiet lurker observing..
>

---

From: Atul Tulshibagwale <[email-masked]>
Date: Wed, 15 Jul 2020 15:49:24 -0700

Agreed. We could drop the SAML subject type in this spec with that
rationale, and it can be defined as needed later.

On Wed, Jul 15, 2020 at 3:22 PM Dick Hardt <[email-masked]> wrote:

>> Tulshibagwale <atultulshi=[email-masked]
>> <atultulshi=[email-masked]>>
>> [email-masked]>, Chris Phillips <[email-masked]>,
>> "id-event@ietf..org <[email-masked]>" <[email-masked]>
>> *CAUTION*: This email originated from outside of the organization. Do
>> not click links or open attachments unless you can confirm the sender and
>> know the content is safe.
>>
>>
>>
>> The RISC Profile’s “ID Token Claims” type does not identify a subject
>> that is an ID Token, it identifies a subject that was the subject of an ID
>> token, or a hash of the token...
>>
>>
>>
>> *CAUTION*: This email originated from outside of the organization. Do
>> not click links or open attachments unless you can confirm the sender and
>> know the content is safe.
>>
>>
>>
>> On Tue, Jul 14, 2020 at 4:09 PM Brian Campbell <
>> [email-masked]> wrote:
>>
>> <[email-masked]>> wrote:
>>
>> On Mon, Jul 13, 2020 at 10:30 AM Chris Phillips <
>> [email-masked] <[email-masked]>> wrote:
>>
>> Hi.
>>
>> Quiet lurker observing..
>>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 15 Jul 2020 17:02:57 -0600

Stepping back a little, I'd venture that the notion of a “durable subject”
came from the fact that all the subject identifier types in the
draft-ietf-secevent-subject-identifiers draft do identify relatively more
permanent subjects. This new type for a session established by a SAML
assertion ID was proposed (nearly 11 months after what was supposed to be
WG last call) and Yaron noted that it was fundamentally pretty different
than what's in the draft now. And he also asked the very reasonable
question of why this specifically for SAML and not other session types. To
which Atul mentioned and proposed adding the RISC ID Token subject
identifier type seemingly suggesting that it was similar to the SAML type.
That, I think, confused the discussion because the RISC ID Token subject
identifier type is not at all like the SAML type. And attempts to point
that out by Yaron and myself while not realizing that it was a precursor to
the alias type further confused the discussion. I apologize for my part in
propagating the confusion.

I gave a +1 to Yaron's because it seemed like the simplest way to try and
deter the WG from adding this type. Simpler anyway than trying to type out
why describing "a subject by the assertion identifier in the SAML assertion
that was used to convey the subject's information" is problematic on
numerous levels. The incorrect assumption that there's a 1:1 relationship
between a SAML assertion and a session, as you point out, being just one of
the problems.

There are big tradeoffs and considerations around what kind of thing is
identified as the subject.  I hope and assume the RISC/CAPE/SSE WG is
managing all that. But this draft-ietf-secevent-subject-identifiers is or
will be extensible with a registry so as to allow additional types to be
defined there, if they are needed and are sensible. I'd suggest we avoid
adding new types to this draft (or really any major changes) at this stage
short of a really compelling reason to do so.