[Openid-specs-risc] [Id-event] SAML subject identifier type
Atul Tulshibagwale
atultulshi at google.com
Tue Jul 14 23:31:40 UTC 2020
+Openid-specs-risc <openid-specs-risc at lists.openid.net>
On Tue, Jul 14, 2020 at 4:30 PM Atul Tulshibagwale <atultulshi at google.com>
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.
>
> 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 <bcampbell at pingidentity.com>
> 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 <yaronf.ietf at gmail.com>
>> 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 <atultulshi at google.com>
>>> *Date: *Tuesday, July 14, 2020 at 23:26
>>> *To: *Yaron Sheffer <yaronf.ietf at gmail.com>
>>> *Cc: *Chris Phillips <Chris.Phillips at canarie.ca>, "id-event at ietf.org" <
>>> id-event at ietf.org>
>>> *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 <yaronf.ietf at gmail.com>
>>> 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 <id-event-bounces at ietf.org> on behalf of Atul
>>> Tulshibagwale <atultulshi=40google.com at dmarc.ietf.org>
>>> *Date: *Tuesday, July 14, 2020 at 00:14
>>> *To: *Chris Phillips <Chris.Phillips at canarie.ca>
>>> *Cc: *"id-event at ietf.org" <id-event at ietf.org>
>>> *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 <
>>> atultulshi at google.com> 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 <
>>> Chris.Phillips at canarie.ca> 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 <id-event-bounces at ietf.org> on behalf of Atul
>>> Tulshibagwale <atultulshi=40google.com at dmarc.ietf.org>
>>> *Date: *Monday, July 13, 2020 at 12:17 PM
>>> *To: *"id-event at ietf.org" <id-event at ietf.org>
>>> *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
>>> Id-event at ietf.org
>>> https://www.ietf.org/mailman/listinfo/id-event
>>>
>>> _______________________________________________ Id-event mailing list
>>> Id-event at ietf.org https://www.ietf.org/mailman/listinfo/id-event
>>>
>>> _______________________________________________
>>> Id-event mailing list
>>> Id-event at ietf.org
>>> 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.*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20200714/96810219/attachment-0001.html>
More information about the Openid-specs-risc
mailing list