Subject: [Id-event] Current vs. alternative subject exammples for SEC Token Draft

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Jun 2017 10:05:00 -0700

We’ve had a long standing thread on how to handle use of “sub” and “iss” in SET.  I’d like to give some examples that we can compare.

Please add your comments. It would be good to reach some conclusion in the next few days if we are going to change the draft for Prague.

Thanks!

Three current draft examples:

1. A SCIM Event looks like:
> { 
>   "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>   "iat": 1458496025,
>   "iss": "https://security.example.com",  
>   "aud": [
>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
>   ],  
>   "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
>   "events": {
>     "urn:ietf:params:scim:event:passwordReset": { }
>   }
> }

2. An OP issued Backchannel Logout (single-sign-out) looks like:
>    {
>       "iss": "https://server.example.com",
>       "sub": "248289761001",
>       "aud": "s6BhdRkqt3",
>       "iat": 1471566154,
>       "jti": "bWJq",
>       "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
>       "events": {
>         "http://schemas.openid.net/event/backchannel-logout": {}
>       }
>    }

3. An RP issued Application Logout Looks like (different issuer):
> {
>    "iss": "https://rp.example.com",
>    "aud": "s6BhdRkqt3",
>    "iat": 1471566154,
>    "jti": "bWJq",
>    "events": {
>      "http://schemas.openid.net/event/risc-logout": {
>        "sub": "248289761001",
>        "iss": "https://server.example.com”,
>        "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
>      }
>    }
> }

I believe the concerns here are:

Use of “sub” and “iss” is inconsistent and moves around.  
SCIM could redefine “sub” as a URI or it could use its own attribute in the payload (introducing more variability).  As long as “sub” is valid to use in SET than profiling specs can redefine sub for their own purposes.  Is this good or bad?
Those writing parsers have to be concerned that when they are parsing a SET they need to know the role of the server OR they have to fully parse the entire object to determine if they are looking at structure 2 or 3.  IOW a lot of implementations have to always check for an embedded “iss” to be sure they have the correct subject.
A concern about the trade-offs if multiple event types are expressed, should they share a common top-level attribute. How does this improve or complicate multi-type events?  In the draft, note that Figure 1 shows an event with a localized extension that adds value without impacting inter-op.
“sid” in Figure 2 of the SET document is in the top-level. We’ve been discussing that additional attributes should be in the payload. Item 3 shows sid in the payload. Which is correct?

=======Possible Options=======

A.  We could say that all SETs must embed sub and iss (if they use iss for identifying subjects) in the payload.  See example 3 above.  This would exclude options 1 and 2 and at least make it consistent that subject information is always in the payload.  

B. A new top-level attribute could be defined which is a JSON object. Inside the JSON object, profiling specs can define how their subjects are addressed. Let’s call it target.  A new common SET format might look something like:

{ 
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://security.example.com",  
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],  
  "target":{
    "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
    "iss": "https://scim.example.com"
  },
  "events": {
    "urn:ietf:params:scim:event:passwordReset": { }
  }
}

Here is an example modified logout 
   {
      "iss": "https://server.example.com",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq”,
      “target”:{
        "sub": "248289761001",
        "sid": "08a5019c-17e1-4977-8f42-65a12843ea02”
      }
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
   }

The above formats address the following:

* Consistent structures
* Flexibility for profiles to target differently but using a common attribute
* Multiple event types share a common target and must be compatible (not sure if this is a plus or minus)
* No conflict around SET issuer vs subject issuer
* SET is substantially different such that existing access token and ID token code will reject consistently (because sub is missing)
* target could also have an attribute that indicates the target “type” such as SCIM resource, OP subject, IPaddress, and so on.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 22 Jun 2017 10:53:30 -0700

Thanks Phil, concrete examples are very useful.

The top level "target" attribute is interesting, it reduces redundancy
across events (when multiple events are present in one SET) but it is
enforcing a single profile per SET.  As you mention, not sure if this is
good or bad.

Also, not sure about the name of the attribute, "target", but I cannot come
up with a better name. "target" sounds like "audience". We need something
along with "events subject". Maybe simply nest the "iss", "sub" and other
right under "events"?

Here is one more example of a SET not using "sub". SETs between an email
provider and an implicit RP would use the OIDC defined "email" attribute
(or "phone_number"):
{
   "iss": "https://rp.example.com",
   "aud": "s6BhdRkqt3",
   "iat": 1471566154,
   "jti": "bWJq",
   "events": {
     "http://schemas.openid.net/event/risc//account-disabled": {
       "reason": "hijacking",
       "email": "[email-masked]",
     }
   }
}

Marius

On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt <[email-masked]> wrote:

> We’ve had a long standing thread on how to handle use of “sub” and “iss”
> in SET.  I’d like to give some examples that we can compare.
>
> Please add your comments. It would be good to reach some conclusion in the
> next few days if we are going to change the draft for Prague.
>
> Thanks!
>
>    - Use of “sub” and “iss” is inconsistent and moves around.
>    - SCIM could redefine “sub” as a URI or it could use its own attribute
>    in the payload (introducing more variability).  As long as “sub” is valid
>    to use in SET than profiling specs can redefine sub for their own
>    purposes.  Is this good or bad?
>    - Those writing parsers have to be concerned that when they are
>    parsing a SET they need to know the role of the server OR they have to
>    fully parse the entire object to determine if they are looking at structure
>    2 or 3.  IOW a lot of implementations have to always check for an embedded
>    “iss” to be sure they have the correct subject.
>    - A concern about the trade-offs if multiple event types are
>    expressed, should they share a common top-level attribute. How does this
>    improve or complicate multi-type events?  In the draft, note that Figure 1
>    shows an event with a localized extension that adds value without impacting
>    inter-op.
>    - “sid” in Figure 2 of the SET document is in the top-level. We’ve
>    been discussing that additional attributes should be in the payload. Item 3
>    shows sid in the payload. Which is correct?
>
>
> A.  We could say that all SETs must embed sub and iss (if they use iss for
> identifying subjects) in the payload.  See example 3 above.  This would
> exclude options 1 and 2 and at least make it consistent that subject
> information is always in the payload.
>
> B. A new top-level attribute could be defined which is a JSON object.
> Inside the JSON object, profiling specs can define how their subjects are
> addressed. Let’s call it target.  A new common SET format might look
> something like:
>
> {
> * SET is substantially different such that existing access token and ID
> token code will reject consistently (because sub is missing)
> * target could also have an attribute that indicates the target “type”
> such as SCIM resource, OP subject, IPaddress, and so on.
>
> Phil
>
> www.independentid.com
> [email-masked]
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Jun 2017 10:58:22 -0700

Agreed to all your comments.  And yes, “target” is not the best name.  Just can’t think of one at the moment.

Thanks for the additional example.  

Phil

> On Jun 22, 2017, at 10:53 AM, Marius Scurtescu <[email-masked]> wrote:
> 
> The top level "target" attribute is interesting, it reduces redundancy across events (when multiple events are present in one SET) but it is enforcing a single profile per SET.  As you mention, not sure if this is good or bad.
> 
> Also, not sure about the name of the attribute, "target", but I cannot come up with a better name. "target" sounds like "audience". We need something along with "events subject". Maybe simply nest the "iss", "sub" and other right under "events"?
> 
> Here is one more example of a SET not using "sub". SETs between an email provider and an implicit RP would use the OIDC defined "email" attribute (or "phone_number"):
> {
>    "iss": "https://rp.example.com <https://rp.example.com/>",
>    "aud": "s6BhdRkqt3",
>    "iat": 1471566154,
>    "jti": "bWJq",
>    "events": {
>      "http://schemas.openid.net/event/risc//account-disabled <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_risc__account-2Ddisabled&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=bZx_nhaRe7CCaR1Y0EIipxH8RqWCWDoBO4_mfvmfyEU&e=>": {
>        "reason": "hijacking",
>        "email": "[email-masked] <mailto:[email-masked]>",
>      }
>    }
> }
> 
> 
> 
> 
> 
> Marius
> 
> On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>   "iss": "https://security.example.com <https://security.example.com/>",  
>>   "aud": [
>>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>>   ],  
>>   "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 <https://scim.example.com/Users/44f6142df96bd6ab61e7521d9>",
>>   "events": {
>>       "iss": "https://server.example.com <https://server.example.com/>",
>>       "sub": "248289761001",
>>       "aud": "s6BhdRkqt3",
>>       "iat": 1471566154,
>>       "jti": "bWJq",
>>         "http://schemas.openid.net/event/backchannel-logout <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=RgQwH23s5wYp0sjLlASIdNXppuZkadGp2-27P2dXoBQ&e=>": {}
>>       }
>>    }
> 
> 
>>    "iss": "https://rp.example.com <https://rp.example.com/>",
>>    "aud": "s6BhdRkqt3",
>>    "iat": 1471566154,
>>    "jti": "bWJq",
>>    "events": {
>>      "http://schemas.openid.net/event/risc-logout <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_risc-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=BzVN38xROsCs1SvZlBnTmxxBVq0Lh_ps97P5cYE7qX4&e=>": {
>>        "sub": "248289761001",
>>        "iss": "https://server.example.com <https://server.example.com/>”,
>   "iss": "https://security.example.com <https://security.example.com/>",  
>   "aud": [
>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>   ],  
>   "target":{
>     "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 <https://scim.example.com/Users/44f6142df96bd6ab61e7521d9>",
>     "iss": "https://scim.example.com <https://scim.example.com/>"
>   },
>   "events": {
>       "iss": "https://server.example.com <https://server.example.com/>",
>       "aud": "s6BhdRkqt3",
>       "iat": 1471566154,
>       "jti": "bWJq”,
>       “target”:{
>         "sub": "248289761001",
>         "http://schemas.openid.net/event/backchannel-logout <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=RgQwH23s5wYp0sjLlASIdNXppuZkadGp2-27P2dXoBQ&e=>": {}
>       }
>    }
> 
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=VOv1b-76jbGOvpEGO_O-K9g1hDpBzM3wQkPtLKPaSVQ&e=>[email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=q5FKGtE3iGS4X-y8K6yth4An24cPZyVXpNNdMPA8rwU&e=>

---

From: Mike Jones <[email-masked]>
Date: Thu, 22 Jun 2017 19:45:14 +0000

It seems to me that most of the discussions motiving the proposals being made have been implicitly assuming that SETs are about digital identities.  In many of our use cases, they will be, which is great.  I fully support structing events for identity profiles to meet the needs of those use cases, including often having a distinct SET issuer from the digital identity “iss” value and having it and the digital identity “sub” be in the event structure, when needed.

But just like JWTs are great for digital identities (consider ID Tokens) but are used in completely unrelated ways as well (such as Caller-ID standards), SETs should be great for digital identities (consider RISC and SCIM profiles) but also be great for unrelated use cases.

In some use cases there will be only one “iss” and the “sub” may be very different from those we use for identities.  We would be doing everyone a disservice to many use cases if we tried to force that “sub” and “iss” be present at the event level, when those profiles don’t need it there.

We shouldn’t make every SET use more complicated syntax that only more advanced use cases actually need.  Therefore, we should leave the “sub” and other claims descriptions as they are.  Right now it’s general purpose and simple.  Let’s not needlessly break that.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, June 22, 2017 12:58 PM
To: Marius Scurtescu <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC Token Draft

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Jun 22, 2017, at 10:53 AM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Here is one more example of a SET not using "sub". SETs between an email provider and an implicit RP would use the OIDC defined "email" attribute (or "phone_number"):
{
   "iss": "https://rp.example.com<https://rp.example.com/>",
   "aud": "s6BhdRkqt3",
   "iat": 1471566154,
   "jti": "bWJq",
   "events": {
     "http://schemas.openid.net/event/risc//account-disabled<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_risc__account-2Ddisabled&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=bZx_nhaRe7CCaR1Y0EIipxH8RqWCWDoBO4_mfvmfyEU&e=>": {
       "reason": "hijacking",
       "email": "[email-masked]<mailto:[email-masked]>",
     }
   }
}

Marius

On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
We’ve had a long standing thread on how to handle use of “sub” and “iss” in SET.  I’d like to give some examples that we can compare.

Thanks!

  "iss": "https://security.example.com<https://security.example.com/>",

2. An OP issued Backchannel Logout (single-sign-out) looks like:
   {
      "iss": "https://server.example.com<https://server.example.com/>",
      "sub": "248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=RgQwH23s5wYp0sjLlASIdNXppuZkadGp2-27P2dXoBQ&e=>": {}
      }
   }

3. An RP issued Application Logout Looks like (different issuer):
{
   "iss": "https://rp.example.com<https://rp.example.com/>",
   "aud": "s6BhdRkqt3",
   "iat": 1471566154,
   "jti": "bWJq",
   "events": {
     "http://schemas.openid.net/event/risc-logout<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_risc-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=BzVN38xROsCs1SvZlBnTmxxBVq0Lh_ps97P5cYE7qX4&e=>": {
       "sub": "248289761001",
       "iss": "https://server.example.com<https://server.example.com/>”,
       "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
     }
   }
}

  *   Use of “sub” and “iss” is inconsistent and moves around.
  *   SCIM could redefine “sub” as a URI or it could use its own attribute in the payload (introducing more variability).  As long as “sub” is valid to use in SET than profiling specs can redefine sub for their own purposes.  Is this good or bad?
  *   Those writing parsers have to be concerned that when they are parsing a SET they need to know the role of the server OR they have to fully parse the entire object to determine if they are looking at structure 2 or 3.  IOW a lot of implementations have to always check for an embedded “iss” to be sure they have the correct subject.
  *   A concern about the trade-offs if multiple event types are expressed, should they share a common top-level attribute. How does this improve or complicate multi-type events?  In the draft, note that Figure 1 shows an event with a localized extension that adds value without impacting inter-op.
  *   “sid” in Figure 2 of the SET document is in the top-level. We’ve been discussing that additional attributes should be in the payload. Item 3 shows sid in the payload. Which is correct?

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://security.example.com<https://security.example.com/>",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],
  "target":{
    "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
    "iss": "https://scim.example.com<https://scim.example.com/>"
  },
  "events": {
    "urn:ietf:params:scim:event:passwordReset": { }
  }
}

Here is an example modified logout
   {
      "iss": "https://server.example.com<https://server.example.com/>",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq”,
      “target”:{
        "sub": "248289761001",
        "sid": "08a5019c-17e1-4977-8f42-65a12843ea02”
      }
      "events": {
        "http://schemas.openid.net/event/backchannel-logout<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=RgQwH23s5wYp0sjLlASIdNXppuZkadGp2-27P2dXoBQ&e=>": {}
      }
   }

* Consistent structures

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=VOv1b-76jbGOvpEGO_O-K9g1hDpBzM3wQkPtLKPaSVQ&e=>
[email-masked]<mailto:[email-masked]>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=q5FKGtE3iGS4X-y8K6yth4An24cPZyVXpNNdMPA8rwU&e=>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 22 Jun 2017 13:02:07 -0700

We agree on the objectives but we disagree on what defines simple and interoperable. 

I foresee a lot of incompatibilities emerging based on the current draft. 

We have a lot of "if this" exception logic trying to permit the OpenId specs to remain unchanged at the cost of clarity for general use. 

In the general, the subject of events are often expressed as composites (more than one attribute).  The connect use of sub and iss is but one example. 

Re-using iss as the part of the subject causes confusion outside of Connect because it appears inconsistent to those that cannot take the shortcut of dual meaning use of iss. Within Connect causes inconsistency when RPs issue events because they need two iss values. One for sub and one for the set issuer. 

IMO the spec needs a lot of clarifying language or a more universal and consistent way to express simple and composite subjects. 

I am looking at a couple more options this aft for the groups consideration. 

Phil

> On Jun 22, 2017, at 12:45 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 22 Jun 2017 14:30:21 -0700

Digital identities were an implicit assumption, definitely for me, and we
should make sure that SETs can be profiled for other use cases as well (for
example networking protocols). Thanks for clarifying this Mike.

At the same time, digital identities are the main driver of requirements
for security events, we have to make sure SETs are a good fit for them.
Having the SET spec on its own being both insecure (the confusion problem)
and not covering all uses cases (RP created SETs) does not sound right to
me. Asking each profile to address these issues is not reasonable in my
view.

The solutions proposed so far do not prevent in any way non-digital
identity profiles.

As Phil mentioned, I think the main disagreement is around the level of
complexity. Another smaller disagreement to me is considering digital
identity use cases as advanced or special. To me these are the main use
cases, I would like to see a solid solution for them.

All that being said, I think we made good progress on today's call and I am
sure that face to face meetings will help a lot. Looking forward to crack
these issues in Prague.

Marius

On Thu, Jun 22, 2017 at 12:45 PM, Mike Jones <[email-masked]>
wrote:

> It seems to me that most of the discussions motiving the proposals being
> made have been implicitly assuming that SETs are about digital identities.
> In many of our use cases, they will be, which is great.  I fully support
> structing events for identity profiles to meet the needs of those use
> cases, including often having a distinct SET issuer from the digital
> identity “iss” value and having it and the digital identity “sub” be in the
> event structure, when needed.
>
>
>
> But just like JWTs are great for digital identities (consider ID Tokens)
> but are used in completely unrelated ways as well (such as Caller-ID
> standards), SETs should be great for digital identities (consider RISC and
> SCIM profiles) but also be great for unrelated use cases.
>
>
>
> In some use cases there will be only one “iss” and the “sub” may be very
> different from those we use for identities.  We would be doing everyone a
> disservice to many use cases if we tried to force that “sub” and “iss” be
> present at the event level, when those profiles don’t need it there.
>
>
>
> We shouldn’t make every SET use more complicated syntax that only more
> advanced use cases actually need.  Therefore, we should leave the “sub” and
> other claims descriptions as they are.  Right now it’s general purpose and
> simple.  Let’s not needlessly break that.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] * On Behalf Of *Phil
> Hunt
> *Sent:* Thursday, June 22, 2017 12:58 PM
> *To:* Marius Scurtescu <[email-masked]>
> *Cc:* ID Events Mailing List <[email-masked]>
> *Subject:* Re: [Id-event] Current vs. alternative subject exammples for
> SEC Token Draft
>
>
>
> Also, not sure about the name of the attribute, "target", but I cannot
> come up with a better name. "target" sounds like "audience". We need
> something along with "events subject". Maybe simply nest the "iss", "sub"
> and other right under "events"?
>
>
>
>      "http://schemas.openid.net/event/risc//account-disabled
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_risc__account-2Ddisabled&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=bZx_nhaRe7CCaR1Y0EIipxH8RqWCWDoBO4_mfvmfyEU&e=>":
> {
>
>        "reason": "hijacking",
>
>   "*jti*": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>
>   "*iat*": 1458496025,
>
>   "*iss*": "https://security.example.com",
>
>   "*aud*": [
>
>       "*iss*": "https://server.example.com",
>
>       "sub": "248289761001",
>
>       "*aud*": "s6BhdRkqt3",
>
>       "*iat*": 1471566154,
>
>       "*jti*": "bWJq",
>
>       "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02",
>
>       "events": {
>
>         "http://schemas.openid.net/event/backchannel-logout
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=RgQwH23s5wYp0sjLlASIdNXppuZkadGp2-27P2dXoBQ&e=>":
> {}
>
>       }
>
>    }
>
>
>
>    "*iss*": "https://rp.example.com",
>
>    "*aud*": "s6BhdRkqt3",
>
>    "*iat*": 1471566154,
>
>    "*jti*": "bWJq",
>
>    "events": {
>
>      "http://schemas.openid.net/event/risc-logout
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_risc-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=BzVN38xROsCs1SvZlBnTmxxBVq0Lh_ps97P5cYE7qX4&e=>":
> {
>
>        "sub": "248289761001",
>
>        "*iss*": "https://server.example.com”,
>
>        "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02"
>
>      }
>
>    }
>
> }
>
>
>
>   "*jti*": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>
>   "*iat*": 1458496025,
>
>   "*iss*": "https://security.example.com",
>
>   "*aud*": [
>
>     "*iss*": "https://scim.example.com"
>
>   },
>
>   "events": {
>
>       "*iss*": "https://server.example.com",
>
>       "*aud*": "s6BhdRkqt3",
>
>       "*iat*": 1471566154,
>
>       "*jti*": "bWJq”,
>
>       “target”:{
>
>         "sub": "248289761001",
>
>         "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02”
>
>       }
>
>       "events": {
>
>         "http://schemas.openid.net/event/backchannel-logout
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=RgQwH23s5wYp0sjLlASIdNXppuZkadGp2-27P2dXoBQ&e=>":
> {}
>
>       }
>
>    }
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=VOv1b-76jbGOvpEGO_O-K9g1hDpBzM3wQkPtLKPaSVQ&e=>
>
> [email-masked]
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g5E8l-HYjMiu66Jg-Fde1cBg36X7TuuHp8dxJ7sSYyk&s=q5FKGtE3iGS4X-y8K6yth4An24cPZyVXpNNdMPA8rwU&e=>
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 22 Jun 2017 14:40:04 -0700

On Thu, Jun 22, 2017 at 1:21 PM, Andrew Nash <[email-masked]> wrote:

> Hey Folks,
>
> sorry to be inserted late - it appears that I have not been getting
> updates from the mail server
>

The mail server sent me a message earlier that I have to reactivate my
account because of bounces, not sure what's up with that.

>
> Looking over the 2 threads that appear to be related to this topic trying
> to catch up it seems that a lot of issues have been juxtaposed
>
> it seems to me that continued use of the top level subject name is
> reasonable as long as the SET/event level subject can be included as well
>

Yes, we could allow sub at both levels. Honestly not sure if that's a good
idea, flexibility leads to complexity.

Phil proposed to group all sub related attributes in one top level
attribute for now called "target" (which would be at the same level as
"events"). This brings sub higher up and gets rid of redundancy, but then
all events in one SET must belong to the same profile (which maybe is a
good thing).

> --Andrew
>> Please add your comments. It would be good to reach some conclusion in
>> the next few days if we are going to change the draft for Prague.
>>
>>
>>
>> Thanks!
>>
>>
>>
>>    - SCIM could redefine “sub” as a URI or it could use its own
>>    attribute in the payload (introducing more variability).  As long as “sub”
>>    is valid to use in SET than profiling specs can redefine sub for their own
>> A.  We could say that all SETs must embed sub and iss (if they use iss
>> for identifying subjects) in the payload.  See example 3 above.  This would

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Jun 2017 14:42:59 -0700

I’ve been noticing a number of people are bouncing particularly on Google domains.

Phil

> On Jun 22, 2017, at 2:40 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> On Thu, Jun 22, 2017 at 1:21 PM, Andrew Nash <[email-masked] <mailto:[email-masked]>> wrote:
> Hey Folks,
> 
> sorry to be inserted late - it appears that I have not been getting updates from the mail server
> 
> The mail server sent me a message earlier that I have to reactivate my account because of bounces, not sure what's up with that.
>  
> 
> Looking over the 2 threads that appear to be related to this topic trying to catch up it seems that a lot of issues have been juxtaposed 
> 
> it seems to me that continued use of the top level subject name is reasonable as long as the SET/event level subject can be included as well 
> 
> Yes, we could allow sub at both levels. Honestly not sure if that's a good idea, flexibility leads to complexity.
> 
> Phil proposed to group all sub related attributes in one top level attribute for now called "target" (which would be at the same level as "events"). This brings sub higher up and gets rid of redundancy, but then all events in one SET must belong to the same profile (which maybe is a good thing).
> 
> 
> --Andrew 
> 
> 
> 
> On Thu, Jun 22, 2017 at 12:45 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>   <>
> From: Id-event [mailto:id-event-bounces@ietf <mailto:id-event-bounces@ietf>.org] On Behalf Of Phil Hunt
> To: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
> Cc: ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> www.independentid.com <>
> [email-masked] <>
> On Jun 22, 2017, at 10:53 AM, Marius Scurtescu <[email-masked] <>> wrote:
> 
>  
> 
>    "iss": "https://rp.example.com <>",
> 
>    "aud": "s6BhdRkqt3",
> 
>    "iat": 1471566154,
> 
>    "jti": "bWJq",
> 
>    "events": {
> 
>      "http://schemas.openid.net/event/risc//account-disabled <>": {
> 
>        "reason": "hijacking",
> 
>        "email": "[email-masked] <>",
> 
>      }
> 
>    }
> 
> }
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> Marius
> 
>  
> 
> On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt <[email-masked] <>> wrote:
> 
>   "iss": "https://security.example.com <>",  
> 
>   "aud": [
> 
>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <>",
> 
>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <>"
> 
>   ],  
> 
>   "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 <>",
> 
>   "events": {
> 
>       "iss": "https://server.example.com <>",
> 
>       "sub": "248289761001",
> 
>       "aud": "s6BhdRkqt3",
> 
>       "iat": 1471566154,
> 
>       "jti": "bWJq",
> 
>         "http://schemas.openid.net/event/backchannel-logout <>": {}
> 
>       }
> 
>    }
> 
>  
> 
>    "iss": "https://rp.example.com <>",
> 
>    "aud": "s6BhdRkqt3",
> 
>    "iat": 1471566154,
> 
>    "jti": "bWJq",
> 
>    "events": {
> 
>      "http://schemas.openid.net/event/risc-logout <>": {
> 
>        "sub": "248289761001",
> 
>        "iss": "https://server.example.com <>”,
> 
>   "iss": "https://security.example.com <>",  
> 
>   "aud": [
> 
>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <>",
> 
>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <>"
> 
>   ],  
> 
>   "target":{
> 
>     "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 <>",
> 
>     "iss": "https://scim.example.com <>"
> 
>   },
> 
>   "events": {
> 
>       "iss": "https://server.example.com <>",
> 
>       "aud": "s6BhdRkqt3",
> 
>       "iat": 1471566154,
> 
>       "jti": "bWJq”,
> 
>       “target”:{
> 
>         "sub": "248289761001",
> 
>         "http://schemas.openid.net/event/backchannel-logout <>": {}
> 
>       }
> 
>    }
> 
>  
> 
> www.independentid.com <>
> [email-masked] <>
> [email-masked] <>
> https://www.ietf.org/mailman/listinfo/id-event <>
>  
> 
> 
> https://www.ietf.org/mailman/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=zNO_hBLHPKbL4wzYqvJIK525mHeXlLkmrNJMS-1o6Lk&s=sHDaBcGGrzLOnn5ZitvEuoKL8Q4-jOH5ynzsF4Aj1Lk&e=>listinfo/id-event
> 
> 
>