Re: [Id-event] SAML subject identifier type
Atul Tulshibagwale <atultulshi@google.com> Wed, 15 July 2020 22:49 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 5AF523A0AB8 for <id-event@ietfa.amsl.com>; Wed, 15 Jul 2020 15:49:40 -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 p1tEJW3p7qg9 for <id-event@ietfa.amsl.com>; Wed, 15 Jul 2020 15:49:37 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 227233A0ABB for <id-event@ietf.org>; Wed, 15 Jul 2020 15:49:37 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id l19so1937261ybl.1 for <id-event@ietf.org>; Wed, 15 Jul 2020 15:49:37 -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=HFDgmbTHz9EwGM3oAvOXvJY1w6cKMEb3fYw9TDd25ls=; b=QtuO5PhMMomfFMYVznK5aYrI3liHqxpw1dNNN3pfih2bB0gaykFWArEYZvTCGat6AL WVmQx2+fD2OTwpCFYrxkx/QbaCJu/gumUZuzuLOSeGJmyxupm/XGUpnBwcSFNUDDeSps oyRi87h5QZZCGNs3rQxQWKX5WXbwAcfV/5TJ+FINtGmKLKBhrFU/UifQwiGJKrnaYhYJ TUqUuzSBLBl10LjURQbnxHJLgTRVmMZVgd6jPgsdoACuARsWwsdf5ypU9L84VxdG6mLd 5lTF20DxhXZXpyMHy7BTeBQhcw4nDqqK2PGI2lckfY6qzc03Az7LGOMPCwGRnIRL5379 ZCkA==
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=HFDgmbTHz9EwGM3oAvOXvJY1w6cKMEb3fYw9TDd25ls=; b=ngOb7k9xs9ppFKJNVLSXSUfxk22Y78uZyHy7GAGXBsj2LZuDvub3r+eQ8I4PevZhrr gfT7IyWPPjiR4W0J6zbtgioMcPWrhG9BsQChkPIKuMVdf67p1Eh4g77TvWhkGH62LsS+ 3eNk7fNtEoqqKpg2heR9IyvtGkzHg+SPkcm1KJHPtBpI3ZmgWd1645k55AHgDhgDvb8r PWynsu7S5TLJE6XDQDmjy1woD7ziOtjH8ycqErs7HMQ+EgmhOZHtO6tojvW/kyPmjox4 dg0Qnq+/N+eVkz80ZGfrVMPLfNl2vZ9LU7bjtr/GdyEmBOLpoxIo491FjfD/4a0xsch4 zVCA==
X-Gm-Message-State: AOAM5314CAyvPnYCOA+L6lKqOxRJPZz1OjqO14+fOAnfAjpS7u2HrWRT YH5Icxp7oLD8W5xhv1/KCvYiyk6gHqwgE8DtC0T5GA==
X-Google-Smtp-Source: ABdhPJxPrQkd9u/jJ9HPvCeyMWsw8M2SDSXdsyKkV52ql4nYL9eGc1azMftu7bU08OStiB3lFUcrTnNO03QtUWAblAY=
X-Received: by 2002:a25:bc13:: with SMTP id i19mr1864373ybh.391.1594853375879; Wed, 15 Jul 2020 15:49:35 -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> <C62035F9-E7D8-4CA4-89A3-2BE6DE941CE3@amazon.com> <CAMCkG5snqNuDAYMXZiri=ZJ7=y9d=-1jCnwV0FcGXVzZnX6+gA@mail.gmail.com> <9CC41112-7947-41E1-9584-6DEB625BBEEA@amazon.com> <MN2PR00MB068653B00930B9E02E2286E5F57E0@MN2PR00MB0686.namprd00.prod.outlook.com> <CAD9ie-tE4=nsmvMy25GXHDRPX32oN=nK0EH0UoHKM9A-XBXb3g@mail.gmail.com>
In-Reply-To: <CAD9ie-tE4=nsmvMy25GXHDRPX32oN=nK0EH0UoHKM9A-XBXb3g@mail.gmail.com>
From: Atul Tulshibagwale <atultulshi@google.com>
Date: Wed, 15 Jul 2020 15:49:24 -0700
Message-ID: <CAMCkG5upG87tMS13R5BGeYjushPf4LeVkmbRZtOvP-s38KygCg@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Brian Campbell <bcampbell@pingidentity.com>, Chris Phillips <Chris.Phillips@canarie.ca>, "id-event@ietf.org" <id-event@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f0944105aa82bcb1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/aR1-IkJbUGX4c3x4mnol1Ckk2fA>
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: Wed, 15 Jul 2020 22:49:40 -0000
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 <dick.hardt@gmail.com> wrote: > +1 > > On Wed, Jul 15, 2020 at 3:21 PM Mike Jones <Michael.Jones= > 40microsoft.com@dmarc.ietf.org> 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 <id-event-bounces@ietf.org> *On Behalf Of *Richard >> Backman, Annabelle >> *Sent:* Wednesday, July 15, 2020 2:25 PM >> *To:* Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org>; >> Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> >> *Cc:* Yaron Sheffer <yaronf.ietf@gmail.com>; Brian Campbell < >> bcampbell@pingidentity.com>; Chris Phillips <Chris.Phillips@canarie.ca>; >> id-event@ietf.org >> *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 <id-event-bounces@ietf.org> on behalf of Atul >> Tulshibagwale <atultulshi=40google..com@dmarc.ietf.org >> <atultulshi=40google.com@dmarc.ietf.org>> >> *Date: *Wednesday, July 15, 2020 at 12:47 PM >> *To: *"Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org> >> *Cc: *Yaron Sheffer <yaronf.ietf@gmail.com>, Brian Campbell < >> bcampbell@pingidentity.com>, Chris Phillips <Chris.Phillips@canarie.ca>, >> "id-event@ietf..org <id-event@ietf.org>" <id-event@ietf.org> >> *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= >> 40amazon.com@dmarc.ietf.org> 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 <id-event-bounces@ietf.org> on behalf of Atul >> Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org> >> *Date: *Tuesday, July 14, 2020 at 4:32 PM >> *To: *Brian Campbell <bcampbell@pingidentity.com> >> *Cc: *Yaron Sheffer <yaronf.ietf@gmail.com>, Chris Phillips < >> Chris.Phillips@canarie.ca>, "id-event@ietf.org" <id-event@ietf.org> >> *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 < >> 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 >> <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 >> <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 <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.* >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >
- [Id-event] SAML subject identifier type Atul Tulshibagwale
- Re: [Id-event] SAML subject identifier type Chris Phillips
- Re: [Id-event] SAML subject identifier type Atul Tulshibagwale
- Re: [Id-event] SAML subject identifier type Atul Tulshibagwale
- Re: [Id-event] SAML subject identifier type Yaron Sheffer
- Re: [Id-event] SAML subject identifier type Atul Tulshibagwale
- Re: [Id-event] SAML subject identifier type Yaron Sheffer
- Re: [Id-event] SAML subject identifier type Brian Campbell
- Re: [Id-event] SAML subject identifier type Atul Tulshibagwale
- Re: [Id-event] SAML subject identifier type Atul Tulshibagwale
- Re: [Id-event] SAML subject identifier type Richard Backman, Annabelle
- Re: [Id-event] SAML subject identifier type Atul Tulshibagwale
- Re: [Id-event] SAML subject identifier type Richard Backman, Annabelle
- Re: [Id-event] SAML subject identifier type Mike Jones
- Re: [Id-event] SAML subject identifier type Dick Hardt
- Re: [Id-event] SAML subject identifier type Atul Tulshibagwale
- Re: [Id-event] SAML subject identifier type Brian Campbell
- Re: [Id-event] SAML subject identifier type Mike Jones