Re: [Id-event] SAML subject identifier type

[Dick Hardt <[e-mail]>]

+1

On Wed, Jul 15, 2020 at 3:21 PM Mike Jones <Michael.Jones=
[e-mail]> 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.
>
>
>
> Let’s keep this simple, while meeting the immediately known needs.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Id-event <[e-mail]> *On Behalf Of *Richard
> Backman, Annabelle
> *Sent:* Wednesday, July 15, 2020 2:25 PM
> *To:* Atul Tulshibagwale <atultulshi=[e-mail]>;
> Richard Backman, Annabelle <richanna=[e-mail]>
> *Cc:* Yaron Sheffer <[e-mail]>; Brian Campbell <
> [e-mail]>; Chris Phillips <[e-mail]>;
> [e-mail]
> *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
>    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.
>
>
>
> –
>
> Annabelle Backman (she/her)
>
> AWS Identity
>
> *https://aws.amazon.com/identity/ <https://aws.amazon.com/identity/>*
>
>
>
>
>
> *From: *Id-event <[e-mail]> on behalf of Atul
> Tulshibagwale <atultulshi=[e-mail]>
> *Date: *Wednesday, July 15, 2020 at 12:47 PM
> *To: *"Richard Backman, Annabelle" <richanna=[e-mail]>
> *Cc: *Yaron Sheffer <[e-mail]>, Brian Campbell <
> [e-mail]>, Chris Phillips <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *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.
>
>
>
> 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=
> [e-mail]> 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:
>
> *  a token identifier (e.g. "jti") for a revoked token.
>
>
>
> –
>
> Annabelle Backman (she/her)
>
> AWS Identity
>
> https://aws.amazon.com/identity/
>
>
>
>
>
> *From: *Id-event <[e-mail]> on behalf of Atul
> Tulshibagwale <atultulshi=[e-mail]>
> *Date: *Tuesday, July 14, 2020 at 4:32 PM
> *To: *Brian Campbell <[e-mail]>
> *Cc: *Yaron Sheffer <[e-mail]>, Chris Phillips <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
> *Date: *Tuesday, July 14, 2020 at 23:26
> *To: *Yaron Sheffer <[e-mail]>
> *Cc: *Chris Phillips <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *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 <[e-mail]
> <[e-mail]>> 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 <[e-mail]> on behalf of Atul
> Tulshibagwale <atultulshi=[e-mail]
> <[e-mail]..org>>
> *Date: *Tuesday, July 14, 2020 at 00:14
> *To: *Chris Phillips <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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:
>
> 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 <[e-mail]>
> 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 <[e-mail]
> <[e-mail]>> wrote:
>
> 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
> <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>
>
>
>
> 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 <[e-mail]> on behalf of Atul
> Tulshibagwale <atultulshi=[e-mail]>
> *Date: *Monday, July 13, 2020 at 12:17 PM
> *To: *"[e-mail]" <[e-mail]>
> *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
> <https://github.com/richanna/secevent/pull/1>.
>
>
>
> Thanks,
>
> Atul
>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
> _______________________________________________ Id-event mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/id-event
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> 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.*
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>