Shared Context Handle document

[Atul Tulshibagwale]

Hi all,

I finally have a draft of the Shared Context Handle document. I have placed it in the shared folder, here: 

https://docs.google.com/document/d/1dcJcsfzy4TjRtSrE2J0vGQyb4RLvVaUeisQCc7tFvXo/edit#

Please review and provide feedback.

Thanks,

Atul Tulshibagwale Software Engineer +14157613123 Mobile 1600 Amphitheatre Parkway, Mountain View, CA 94043

[ALI Asad]

Hi Atul,

 

Thanks for writing down this definition of shared context handle. We had been dancing around this topic for quite some time, with different interpretation of what this handle really means.

 

It is good to see that SCH is not defining a new identifier, but reusing an existing identifier, or a combination thereof. This is a good design. One suggestion, instead of explicitly mentioning the value of existing identifiers, can we simply use a reference to them. E.g. instead of,

 

"sch": "us...@idpcustomerA.com"

We have,

"sch": "email"

 

This will remove ambiguity, by relying on already defined JWT/SET claim names. Perhaps this is already the intent.

 

Best regards,

--- Asad

Thanks,

 

 

--
You received this message because you are subscribed to the Google Groups "caep-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to caep-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/CAMCkG5umQA%2BN33KQ5R9DE7zD0t1NYChw2knCwmFikbvcZ2%3DjUg%40mail.gmail.com.

[Jordan Wright]

Thanks for sharing this Atul!

I agree completely that instead of trying to define a new opaque identifier, we can treat SCH's as a combination of one or more identifiers. I think this will solve what we're going for with CAEP.

How do you think this compares to the notion of subject identifiers in RISC? I'd have to go through the details, but it seems as though we might be able to reuse the existing work from RISC if we:

• Created new subject identifier types for the types of subjects we care about (e.g. SAML request IDs) that don't currently exist, or otherwise define the ability for the publisher and subscriber to agree on subject types out of band
• Create a new subject type for "sch" which includes one or more non-sch subject identifiers.

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/PR2P264MB0206281446B44269DC73F5BE90710%40PR2P264MB0206.FRAP264.PROD.OUTLOOK.COM.

--

		Jordan Wright  / Principal R&D Engineer   jwr...@duo.com   Duo.com
---------- The Most Loved Company in Security

[Rob Otto]

Hi everyone - great work on the document, Atul. Thanks for putting this together.

I've added a comment, but wanted to raise this question on the list as well. Is it really a good idea to be using non-session-related identifiers between IDP and SP? I'm not convinced that this is a good idea from a privacy point of view. The idea I had in mind is that the SP would register for updates from the IDP in the context of a federated session (SAML/OIDC/OAuth) using whatever "natural identifier" already exists (such as the SAML Request ID, or perhaps an OIDC state or token hash). This allows the IDP to selectively share updates with the appropriate SPs based on a policy that it controls.

How would an IDP even make a decision as to whether a service provider is entitled to register for updates regarding a particular user (or user/device) if we are not linking this to a federated session? 

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/CADV%3DJMigrJBs8bOMgeOYCXM0XMXxDnbh_r6xKyjupJ%2BCq31Ddw%40mail.gmail.com.

--

	Rob Otto EMEA Field CTO/Solutions Architect rober...@pingidentity.com c: +44 (0) 777 135 6092
Connect with us:

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.

[David Waite]

I was hoping to discuss this some today :-)

Some of what we are talking about appear to be profiles around secevents - MDM systems, federation systems, Wifi, etc. each of these may use one or more “typed identifiers” - username, device id, MAC, session id, per-client pseudonymous identifier, Etc. Treating these as separate profiles may have advantages, such as getting participants from the various industries to participate and commit. 

Within a security domain, you can work to correlate and reason about all of these. That reasoning is most likely what you would share as account and session level events to partners.

That’s not to say that other profiles might have value to be cross-organizational as well. RISC is a prime example. 

-DW

To unsubscribe from this group and stop receiving emails from it, send an email to caep-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/CAMCkG5umQA%2BN33KQ5R9DE7zD0t1NYChw2knCwmFikbvcZ2%3DjUg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "caep-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to caep-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/PR2P264MB0206281446B44269DC73F5BE90710%40PR2P264MB0206.FRAP264.PROD.OUTLOOK.COM.

--

		Jordan Wright  / Principal R&D Engineer   jwr...@duo.com   Duo.com
---------- The Most Loved Company in Security

--
You received this message because you are subscribed to the Google Groups "caep-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to caep-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/CADV%3DJMigrJBs8bOMgeOYCXM0XMXxDnbh_r6xKyjupJ%2BCq31Ddw%40mail.gmail.com.

--

	Rob Otto EMEA Field CTO/Solutions Architect rober...@pingidentity.com c: +44 (0) 777 135 6092
Connect with us:

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.

--

You received this message because you are subscribed to the Google Groups "caep-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to caep-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/CABh6VREZmzg3ZbCASqeQjOn0My_b-qCS%3DdwvBU4osW1QvmJDSw%40mail.gmail.com.

--

	David Waite Principal Technical Architect, CTO Office dwa...@pingidentity.com w: 303 468 2855

[Adam Hampton]

The SET draft allows posting a list of "aliases" for the subject in the hopes of finding one the receiving party can correlate to an identity/device/session/etc.  I think we might really just be specifying some additional profiles that are really new kinds of aliases.  For reference: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-05#section-3.5 

--Adam

On Thursday, November 14, 2019 at 9:49:50 AM UTC-6, David Waite wrote:

I was hoping to discuss this some today :-)

Some of what we are talking about appear to be profiles around secevents - MDM systems, federation systems, Wifi, etc. each of these may use one or more “typed identifiers” - username, device id, MAC, session id, per-client pseudonymous identifier, Etc. Treating these as separate profiles may have advantages, such as getting participants from the various industries to participate and commit. 

Within a security domain, you can work to correlate and reason about all of these. That reasoning is most likely what you would share as account and session level events to partners.

That’s not to say that other profiles might have value to be cross-organizational as well. RISC is a prime example. 

-DW

On Thursday, November 14, 2019, 'Rob Otto' via caep-discuss <caep-d...@googlegroups.com> wrote:

Hi everyone - great work on the document, Atul. Thanks for putting this together.

I've added a comment, but wanted to raise this question on the list as well. Is it really a good idea to be using non-session-related identifiers between IDP and SP? I'm not convinced that this is a good idea from a privacy point of view. The idea I had in mind is that the SP would register for updates from the IDP in the context of a federated session (SAML/OIDC/OAuth) using whatever "natural identifier" already exists (such as the SAML Request ID, or perhaps an OIDC state or token hash). This allows the IDP to selectively share updates with the appropriate SPs based on a policy that it controls.

How would an IDP even make a decision as to whether a service provider is entitled to register for updates regarding a particular user (or user/device) if we are not linking this to a federated session? 

On Thu, 14 Nov 2019 at 03:38, 'Jordan Wright' via caep-discuss <caep-d...@googlegroups.com> wrote:

Thanks for sharing this Atul!

I agree completely that instead of trying to define a new opaque identifier, we can treat SCH's as a combination of one or more identifiers. I think this will solve what we're going for with CAEP.

How do you think this compares to the notion of subject identifiers in RISC? I'd have to go through the details, but it seems as though we might be able to reuse the existing work from RISC if we:

• Created new subject identifier types for the types of subjects we care about (e.g. SAML request IDs) that don't currently exist, or otherwise define the ability for the publisher and subscriber to agree on subject types out of band
• Create a new subject type for "sch" which includes one or more non-sch subject identifiers.

To unsubscribe from this group and stop receiving emails from it, send an email to caep-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/CAMCkG5umQA%2BN33KQ5R9DE7zD0t1NYChw2knCwmFikbvcZ2%3DjUg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "caep-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to caep-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/PR2P264MB0206281446B44269DC73F5BE90710%40PR2P264MB0206.FRAP264.PROD.OUTLOOK.COM.

--

		Jordan Wright  / Principal R&D Engineer   jwr...@duo.com   Duo.com
---------- The Most Loved Company in Security

--
You received this message because you are subscribed to the Google Groups "caep-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to caep-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/CADV%3DJMigrJBs8bOMgeOYCXM0XMXxDnbh_r6xKyjupJ%2BCq31Ddw%40mail.gmail.com.

--

	Rob Otto EMEA Field CTO/Solutions Architect rober...@pingidentity.com c: +44 (0) 777 135 6092
Connect with us:

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.

--
You received this message because you are subscribed to the Google Groups "caep-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to caep-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/caep-discuss/CABh6VREZmzg3ZbCASqeQjOn0My_b-qCS%3DdwvBU4osW1QvmJDSw%40mail.gmail.com.