Re: [Id-event] SAML subject identifier type

Atul Tulshibagwale <atultulshi@google.com> Tue, 14 July 2020 23:31 UTC

Return-Path: <atultulshi@google.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F293A0769 for <id-event@ietfa.amsl.com>; Tue, 14 Jul 2020 16:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.589
X-Spam-Level:
X-Spam-Status: No, score=-17.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A6EFCzZbc9G for <id-event@ietfa.amsl.com>; Tue, 14 Jul 2020 16:31:53 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBA03A0745 for <id-event@ietf.org>; Tue, 14 Jul 2020 16:31:53 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id x138so234880ybg.9 for <id-event@ietf.org>; Tue, 14 Jul 2020 16:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ou3426CSW352BI2OIE9KuNqCwquJzyBRnn/j7/xHZg=; b=HFoHUtlfune5dftqyYIdYGbKy3tfwRz6gU6tdDCbCFTIUCE3Yuu8hxiEsUA5GTOirJ N8tDceBI8RiBaLcJBJ7hN4mr+GaNwmQpTYII7jebg1uZKysYZ50kSxBQDWKkkR23E9Ep gctVHkUzBByh5o9cHVdavcKbIzqdNrS5hcT+U4y7RZRQiTFkyG72/Q/u297Z4j6BLZ1o IsVBx88GpAGE4BTa4zFjmnrbB8GVZMXMb1wzUlF5YqrhpRxf0GiqTjlB3e8kyqWsfE1Q veLFEorG/55ab6KRHGx9GUZiIoytvEXEa2ls9R6bZxJtlbNyCS1+WlhGCi/cKNWIY/xh 8bTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6ou3426CSW352BI2OIE9KuNqCwquJzyBRnn/j7/xHZg=; b=f57pNjj4mNBKnNFq+GiUdjwcweei97/rewoue/fV6zuCe2bsJRm+8pJR6+fb8ZyOcL D4CatluNGvOQ+6LEzmX64aLB6y94Ylh8jeGpmVeIP0xY+ajdq2X9RsJV3+vGu6K6X5iB WX6m2zYeqTt1Aeyp8qz4tUzGQHdjKfwzGRDMEyF5he+kJsU1VwZPD4637XHDvCwnOrGt Q96NpbLSNehY1liu9Kk85kFbu47Bb585VsH72PZXqMUFJcaSxMItdOv2CobPQL5aBmkX S6pKPQ5pmebb5gFOyTDOp1JunolQeMHI+jNw09UqQB+0UVc6OgK7Frvh2AHrehUXI9E8 fyGA==
X-Gm-Message-State: AOAM533gvxS+5bbeBdMg0f9TNcne2KdBCgnQVBHeVHaW4v4CHd1/LPq5 Y8/ju+eP6JhMKlg7xCd+ZCz3BA2BYl42n4XYA2PwdA==
X-Google-Smtp-Source: ABdhPJyr/qI/Ch4G6ErDbK/UWVrMXb57mrYz5wZxygvi0+n+u4ViaAV/B8fR3+oSBl4Sdl97Q/Szdfm6gXizoakhIV4=
X-Received: by 2002:a25:c713:: with SMTP id w19mr12016148ybe.130.1594769512335; Tue, 14 Jul 2020 16:31:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAMCkG5thP1JnyBn5qAK0TLqBoa-y53Qnoq=mf-NPLfzSF2U7VQ@mail.gmail.com> <5B3455F1-9F82-40C5-BE22-2E3B715A0CF1@canarie.ca> <CAMCkG5uSQzTGCmFn6DLeXVbA0B0wrcPou8CEjtCQ5BCp3M+eOw@mail.gmail.com> <CAMCkG5uff+WwMRLDr+Lph-TagtwL5jWORg5ruvWLOxkNBM2s0A@mail.gmail.com> <E7D14134-0210-4515-ACA3-2AB5CDDCBF34@gmail.com> <CAMCkG5t+7z7OOLdsD77zj_eM7eYf2wOTGTV9tg5S01FXgcHC0w@mail.gmail.com> <8B77A27C-D5B3-477A-BD0D-8B3D3B818BB0@gmail.com> <CA+k3eCQ+f78Ct59D45SyQ8MnCLbpf6665h48MKpyvBaAA-ezZg@mail.gmail.com> <CAMCkG5ssFt2Dy-pbuuEch7KkBu+goNhSbfepx6dVxrUKChBRBw@mail.gmail.com>
In-Reply-To: <CAMCkG5ssFt2Dy-pbuuEch7KkBu+goNhSbfepx6dVxrUKChBRBw@mail.gmail.com>
From: Atul Tulshibagwale <atultulshi@google.com>
Date: Tue, 14 Jul 2020 16:31:40 -0700
Message-ID: <CAMCkG5vZG=txhkzTSU3QX89mp1ZYnQXMnH+gcVRqzwA_9i-x7Q@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>, Openid-specs-risc <openid-specs-risc@lists.openid.net>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, Chris Phillips <Chris.Phillips@canarie.ca>, "id-event@ietf.org" <id-event@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000488c0105aa6f3612"
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/sAN5BDPD86OHg3zE2bR518J3S9g>
Subject: Re: [Id-event] SAML subject identifier type
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2020 23:31:56 -0000

+Openid-specs-risc <openid-specs-risc@lists.openid.net>

On Tue, Jul 14, 2020 at 4:30 PM Atul Tulshibagwale <atultulshi@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@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@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@google.com>
>>> *Date: *Tuesday, July 14, 2020 at 23:26
>>> *To: *Yaron Sheffer <yaronf.ietf@gmail.com>
>>> *Cc: *Chris Phillips <Chris.Phillips@canarie.ca>, "id-event@ietf.org" <
>>> id-event@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@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@ietf.org> on behalf of Atul
>>> Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org>
>>> *Date: *Tuesday, July 14, 2020 at 00:14
>>> *To: *Chris Phillips <Chris.Phillips@canarie.ca>
>>> *Cc: *"id-event@ietf.org" <id-event@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@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@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@ietf.org> on behalf of Atul
>>> Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org>
>>> *Date: *Monday, July 13, 2020 at 12:17 PM
>>> *To: *"id-event@ietf.org" <id-event@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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/id-event
>>>
>>> _______________________________________________ Id-event mailing list
>>> Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event
>>>
>>> _______________________________________________
>>> Id-event mailing list
>>> Id-event@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.*
>
>