Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Mike Jones <Michael.Jones@microsoft.com> Fri, 10 March 2017 22:30 UTC

Return-Path: <Michael.Jones@microsoft.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 ED4D51293E8 for <id-event@ietfa.amsl.com>; Fri, 10 Mar 2017 14:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 y6oj2Gd_FFAq for <id-event@ietfa.amsl.com>; Fri, 10 Mar 2017 14:29:59 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0094.outbound.protection.outlook.com [104.47.32.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF32F127735 for <id-event@ietf.org>; Fri, 10 Mar 2017 14:29:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5vgp6ax0kJmfNQpbGPwRnSawjRIWOBJGlZjDE6EdfVM=; b=Q9H076d8WAVkMFERNwVzm0SeHnt6SNW6gu0KQcGsAUnz3kJ5mC43+ADUvmmoT6qVaBQbDq9vstDw8+KvbyFvFXeLVDtCrc9PeF2GebTAyrE67RnErGtN1CYWRamb1+3xLGjFizZw4lxp1LAeypecZJAXuXGVssaS5y3chb6MVmU=
Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0503.namprd21.prod.outlook.com (10.172.122.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.0; Fri, 10 Mar 2017 22:29:56 +0000
Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0947.022; Fri, 10 Mar 2017 22:29:56 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Benjamin Kaduk <bkaduk@akamai.com>, Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [Id-event] Thread: Clarifying use of sub and iss in SET tokens
Thread-Index: AQHSkrmW5tqPJIY8NEisvT0PLETCCaGFT4mAgAAhegCAAM4FAIACUTGggAAFSICAAPOOAIAADNgAgAATLACAABCVAIAB7Y+AgABTR/CAArraAIAAAFUQ
Date: Fri, 10 Mar 2017 22:29:55 +0000
Message-ID: <CY4PR21MB0504843781585CCFA4A8DD4EF5200@CY4PR21MB0504.namprd21.prod.outlook.com>
References: <4611E3C8-9772-44EA-940D-077E1EA6247F@oracle.com> <7f44a710-0545-157c-b75e-d46853cf2e06@mit.edu> <4B014CCA-BCBE-4894-9F2F-17DA2541509A@oracle.com> <1bbfcb1f-c554-3baf-e260-fbd475c803bb@mit.edu> <CY4PR21MB0504F24541054228A72FC93FF52F0@CY4PR21MB0504.namprd21.prod.outlook.com> <6e1e3988-43c7-5ac1-529d-4160ced6cc90@akamai.com> <2cd1b77c-ca3c-a773-4068-21da43509e8b@mit.edu> <C2BE4FD7-6090-49C7-88FD-CCBBBC40538C@oracle.com> <CY4PR21MB05041BD15DFB7F4E8097B02BF52F0@CY4PR21MB0504.namprd21.prod.outlook.com> <8BF1F254-AB43-492C-9A3A-D6DC76D23B7A@oracle.com> <63cbe472-09e9-36ff-2970-580450bfcd48@akamai.com> <CY4PR21MB05049EBF9833BD5BA8470BC4F5210@CY4PR21MB0504.namprd21.prod.outlook.com> <7e9c4832-8b59-abf9-3934-4dc286736842@akamai.com>
In-Reply-To: <7e9c4832-8b59-abf9-3934-4dc286736842@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:e::36]
x-ms-office365-filtering-correlation-id: 616ee1ba-fe39-4f67-400a-08d46804fabb
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0503;
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0503; 7:wMEEOtVclVEOjlvYA4V9Jkz7ma/bXbCO8ynPOnl1n1YEy5EyVlXLSbdR3q75YYaT04dwNqlNdj+9CuAikncRGktgScP3QXYjFR7HtE9rtO3BADZogcQsu4DbaANF2bKXXnx4pl5ZDKHHHf5/1SdKmRx2g8GLLYtv17rAzE1M0g2iAt/tZ0H03oQYtSuLQs//r1UGOSI4nM/ARAcV9UxGUsuAMtbgLr3Iwo4F7JBesRIoXO1qDI7H+RzjWwc9+HOUH1DpLMx60+T99A4axGjRC4Yr8RuL0c8OHLpZbNGPNqDP/vYUEalsfaYBocbYhTV8dvGDTzyne55OL8Iy/B+c9cAzmgV9T4TuX4VKgT20m6g=
x-microsoft-antispam-prvs: <CY4PR21MB05036CE6188EE50AD369C13EF5200@CY4PR21MB0503.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(35073007944872)(21748063052155)(21532816269658)(146099531331640)(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR21MB0503; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0503;
x-forefront-prvs: 02426D11FE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(51884002)(377454003)(24454002)(53546006)(6306002)(50986999)(54896002)(76176999)(53936002)(236005)(9686003)(54356999)(7906003)(86612001)(38730400002)(53946003)(606005)(6436002)(4326008)(6506006)(7736002)(74316002)(10090500001)(33656002)(3660700001)(81166006)(8676002)(2906002)(6246003)(229853002)(575784001)(86362001)(551544002)(8936002)(3280700002)(189998001)(2950100002)(99286003)(8990500004)(55016002)(93886004)(77096006)(5005710100001)(10290500002)(106116001)(2900100001)(6116002)(102836003)(790700001)(7696004)(5660300001)(122556002)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0503; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504843781585CCFA4A8DD4EF5200CY4PR21MB0504namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 22:29:55.8833 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0503
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/HiYPgYhnLkBLDTKWCtO7OCwl7jU>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 10 Mar 2017 22:30:05 -0000

Yes, the profiling spec needs to define the claims usage for the event.  This is one example of the application of that rule.

From: Benjamin Kaduk [mailto:bkaduk@akamai.com]
Sent: Friday, March 10, 2017 2:27 PM
To: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt <phil.hunt@oracle.com>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

I had to think a bit about why this didn't feel quite right to me.  I think it's that I wasn't sure how the event consumer would know that the (event) issuer is such an authoritative IdP.  Looking later in the thread, it sounds like maybe the profile specification will make that clear; is that the case?

Thanks,

Ben
On 03/09/2017 12:49 PM, Mike Jones wrote:
One use case for which there is only a single issuer and a single subject is common and straightforward.  One example is when an Identity Provider is authoritative for a digital identity that it is the issuer for.  That IdP can issue events about that digital identity.  I'll note that OpenID Connect uses are of this kind, and that the "sub" value is relative to the issuer - not globally unique.  Trying to make "sub" globally unique would be a breaking change.

                                                       -- Mike

From: Benjamin Kaduk [mailto:bkaduk@akamai.com]
Sent: Wednesday, March 8, 2017 3:47 PM
To: Phil Hunt <phil.hunt@oracle.com><mailto:phil.hunt@oracle.com>; Mike Jones <Michael.Jones@microsoft.com><mailto:Michael.Jones@microsoft.com>
Cc: ID Events Mailing List <id-event@ietf.org><mailto:id-event@ietf.org>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Sorry for the delay.
On 03/07/2017 12:20 PM, Phil Hunt wrote:
Thanks Mike,

Just to be clear. You are expressing a perspective of maintaining the exact format as defined by the ID Token and imposing the limit on all other Events.

If I understand correctly, JWT (RFC7519) has no such limitation on sub and the group *could* choose to profile "sub" to be globally unique for all SET Events. Correct?

What I was trying to do was point out the 3 separate subject identification formats already in the spec and to ask, is this really acceptable (per Yaron's request)?

You and William have indicated a preference to leave it.

Justin and Benjamin did apparently express some concerns. Can they clarify?


My preference would be your "4th option" to always have "sub" and "iss" in the events payload, even if "iss" is the same in the outer envelope and the events payload -- it's unambiguous and easy to interpret.  Mike has mostly convinced me that there exist environments when the two "iss" are absolutely required to be identical and are strictly duplicated (which lends itself naturally to the status quo).  But since I don't understand these cases very well, I'm concerned about how to identify those environments and whether there would be interop issues if such an environment contained an actor that also had to interact with a more generic environment.



My concern is that we are too compatible with existing code. SETs can easily be confused as ID Tokens as existing ID Token parsers will ignore the events attribute and will see all the normal claims for an ID Token as being present.  If you can address this, then I can live with the status quo.


I don't think I have anything to offer to help on the disambiguation of ID tokens and SETs issue.

-Ben



Are they any that have issues with the current draft (in order to get back to Yaron's question)? The current draft allows multiple iss values to appear in different places in the JSON structure based on profiling specification definition.

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=Ijhk2wjlr4V4-fswCLBGE38fdK1gwFfUY66tfJf7a24&e=>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>






On Mar 7, 2017, at 9:29 AM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:

No, it's not possible to require that "sub" be globally unique because for important use cases, it's relative to the issuer.  Trying to force it to be a URI would unnecessarily limit the applicability of the SET spec, causing some applications to simply decide to not use it as a result.

If some use cases want a kind of logout event that's issued by a different party than the IdP, then the current spec lets that new event be defined.  It will require more parameters than the current logout event, but that's OK, since it's used in different contexts.

In my view, it's not editorially lazy to allow events to define what claims they need.  It's an intentional choice, which enables the simple cases to be simply expressed, while also enabling more complicated cases carrying more information to be expressed.

Trying to force the simple events use extra syntax only actually needed for complicated events would be a severe architectural mistake on our part.

                                                       -- Mike

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, March 7, 2017 8:13 AM
To: ID Events Mailing List <id-event@ietf.org<mailto:id-event@ietf.org>>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens


Just to refresh everyone...

As editor, my feeling is we have no *clean* or *simple* solution because we have to use "iss" to mean the issuer of the SET in order to comply with JWT and because OIDC conflates assertion issuer with subject issuer, it makes it difficult to uniquely identify a "sub" value because some events want to use "iss" for 2 purposes (to identify the event issuer vs. the subject issuer).

None of the solutions presented are actually easy to explain. So far, I've sided with Mike and William because they feel it is close enough and it was editorially lazy (say nothing). I am worried that this is actually complex for developers who do not know the history of how JWTs emerged.

Let's look at the examples we already have. Notice that in the current draft, there are 3 separate ways of expressing the subject of an event....

Scenario 1, the event issuer and subject issuer are the same:

   {
      "iss": "https://server.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=aZmCu-T30ddM7EO5MTTcZLtFvxVBsTqvt157yHUeOIU&e=>",
      "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=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=qmlNwMQZyc4wKMGYlcbHv4N_qYgxNWYhJxV9x_obkMQ&e=>": {}
      }
   }

Scenario 2, a relying party is issuing an event, event iss and sub iss are different and thus there are repeat iss values:

   {
     "jti": "fb4e75b5411e4e19b6c0fe87950f7749",

     "sub": "248289761001",
     "iat": 1458496025,
     "iss": "https://my.examplemed.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",
     "aud": [
       "https://rp.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__rp.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=gpNhu-LU43cxIyrYhVcrMto66IZz2Jxwa5lzPpxVTD0&e=>"
     ],
     "events": {
       "https://openid.net/heart/specs/consent.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_specs_consent.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=0Z-ohlyQps3JNPgGR0j_zY-sRZI274Y9zMivRDXjmis&e=>":{
         "iss":"https://connect.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__connect.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=KpM1_m5EiidPDJVV4EzmfBTYG6hneVcT8hymd-6p1BI&e=>",
         "consentUri":[
           "https://terms.examplemed.com/labdisclosure.html#Agree<https://urldefense.proofpoint.com/v2/url?u=https-3A__terms.examplemed.com_labdisclosure.html-23Agree&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=AAdiJeFhv-D7NndiSyTUpmxuwaxrG64CU2JvbKF1lc0&e=>"
         ]
       }
     }
   }

Scenario  3:  sub is universally unique:

   {
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "iat": 1458496025,
     "iss": "https://scim.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__scim.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=LyBq6tEQAe7jo3Yewc_F77-CHuOYZwsa4UYyVPDCFpc&e=>",
     "aud": [
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754<https://urldefense.proofpoint.com/v2/url?u=https-3A__jhub.example.com_Feeds_98d52461fa5bbc879593b7754&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=mOuO83TTWdG12H5jGxLpWICeVgNxA5q5xMAegwYiPeg&e=>",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7<https://urldefense.proofpoint.com/v2/url?u=https-3A__jhub.example.com_Feeds_5d7604516b1d08641d7676ee7&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=SgkQ6fsaS-Le8I4wi1GGygVQsEZLxoN8sZQS3NvgZis&e=>"
     ],
     "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9<https://urldefense.proofpoint.com/v2/url?u=https-3A__scim.example.com_Users_44f6142df96bd6ab61e7521d9&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=FiGG_pwSjXMTe-zrlpNBMrFityNSwQdBVfjvDFMV1QE&e=>",
     "events": {
       "urn:ietf:params:scim:event:passwordReset":
         { "id":"44f6142df96bd6ab61e7521d9"},
       "https://example.com/scim/event/passwordResetExt<https://urldefense.proofpoint.com/v2/url?u=https-3A__example.com_scim_event_passwordResetExt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=l9vO69P8yOSS_2Gd_1ya8bJyBLwhFj_fl3yZG9ovzXo&e=>":
         { "resetAttempts":5}
     }
   }

I believe the current argument is that profiling specs explains how their events are to be parsed. This means for multi-event parsers, subject is inconsistent and potentially not mappable.  The BackChannel Logout event is currently structured for only the OP to issue. However Oracle wants that to be bi-directional so that web sites can notify the IDP/OP that the user has logged out of a specific web site.  If that happens, BackChannel logout will have methods 1 and 2 required.

Would it be possible for events to require that "sub" be globally unique - e.g. expressed as a url.  For example, in order for backchannel to be issued by an OP or an RP, it would be expressed with sub as a URL ("sub": "https://server.example.com/248289761001<https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_248289761001&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=5Rnz1dzOEoK27YDktq_HMGneutBpDod8-iAqU1CgizQ&e=>",):
   {
      "iss": "https://www.exampleapp.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.exampleapp.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=KuoD7Qelh1vowEZDz-WSjpIwC7vlR410B8RPsdfQg20&e=>",
      "sub": "https://server.example.com/248289761001<https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_248289761001&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=5Rnz1dzOEoK27YDktq_HMGneutBpDod8-iAqU1CgizQ&e=>",
      "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=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=qmlNwMQZyc4wKMGYlcbHv4N_qYgxNWYhJxV9x_obkMQ&e=>": {}
      }

At least this way iss is never duplicated and sub is always the addressable subject of the event regardless of the type of event.  That would enable all 3 cases to be expressed one way for all specs.  That seems simple to me (at least from how I would define this in the spec).

I had thought Justin was advocating a 4th option which is to always embed "sub" and "iss" in the event payload.  So you would end up with something like:
   {
     "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
     "iat": 1458496025,
     "iss": "https://my.examplemed.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",
     "aud": [
       "https://rp.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__rp.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=gpNhu-LU43cxIyrYhVcrMto66IZz2Jxwa5lzPpxVTD0&e=>"
     ],
     "events": {
       "https://openid.net/heart/specs/consent.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_specs_consent.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=0Z-ohlyQps3JNPgGR0j_zY-sRZI274Y9zMivRDXjmis&e=>":{
         "sub": "248289761001",
         "iss":"https://my.examplemed.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",
         "consentUri":[
           "https://terms.examplemed.com/labdisclosure.html#Agree<https://urldefense.proofpoint.com/v2/url?u=https-3A__terms.examplemed.com_labdisclosure.html-23Agree&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=AAdiJeFhv-D7NndiSyTUpmxuwaxrG64CU2JvbKF1lc0&e=>"
         ]
       }
     }
   }

Note that in the above example, "iss" would always be present even if "iss" is the *same*.  The rule would be that the iss and sub are in the payload and that addresses the subject of the event. The envelope level is always reserved for event validation and addressing only.  While some would argue this is ugly, I can see some merits as it is at least consistent.


Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=B_jjXc15tMFqi9Ef2x7fWuBKYckJ2pchgc61F80QAWA&e=>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>






On Mar 7, 2017, at 7:26 AM, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:

+1

On 3/6/2017 7:55 PM, Benjamin Kaduk wrote:
On 03/06/2017 06:39 PM, Mike Jones wrote:



Justin, I suspect you didn't see my earlier reply to Phil's note that you also replied to, so I'm repeating it here and sending it to you directly.  (It wouldn't be the first time that DMARC policies caused some of my contributions to be not received by some participants. :-( )

Agreed that this is unclear.  Duplicating information in a protocol *always* introduces an unnecessary error case - the need to define how to handle the situation in which two pieces of information that are required to be identical are different.  Information in a SET should occur at most once.


That seems a dangerous road to tread, as it requires care in defining "information" -- duplicating the same data strings at different levels of the hierarchy of a JSON object may very well not be duplicating information, due to the extra context provided by the hierarchy.  In my mind, it's not a clear case that you should never send the same name/value multiple times in different parts of an object, as sometimes it is good to keep the semantic separation clear.

-Ben


_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
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=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=GvCU0sssYF2cnSpnUau9N2MD6u_C3mtzrBtqNOwmKi0&e=>






_______________________________________________

Id-event mailing list

Id-event@ietf.org<mailto:Id-event@ietf.org>

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=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=Ma3MDbWVFnIyFGL2K_OCpMN37A8gsJRuyz6AIcbA7TA&s=og1z-m3kp2hcMYwqmJGL_8FwUfmQRoyAMzwqOCfMz1E&e=>