Re: [Id-event] Consensus :: Event Subject Claim

Comments in line. 

Phil

> On Dec 15, 2017, at 9:07 AM, Marius Scurtescu <mscurtescu@google.com> wrote:
> 
>> On Thu, Dec 14, 2017 at 6:05 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> Marius, Mark already wrote in another of the consensus calls: “The spec works well for the consent a privacy syntax use cases we are aware of.”  I’m not sure why you’re doubting him now.
>> 
> 
> I am not doubting Mark, I want to understand his use cases.  

> 
>>  
>> 
>> The consent receipt has a string-valued “piiPrincipalId” claim, which could either be used in the SET directly or placed in a “sub” claim.  Frankly, I don’t see any reason why consent receipts wouldn’t continue to use the same claims to identify their subjects that they do today.  (But Mark is authoritative on this subject – not me.)
>> 
> 
> OK, so let's hear from Mark.
>  
>>  
>> 
>>                                                        -- Mike
>> 
>>  
>> 
>> P.S.  Marius, I hope you will refrain from personal attacks in the future.
>> 
> 
> These are not personal attacks Mike, I am sorry you feel like that. I am frustrated because I feel that we don't have a functioning working group.
> 
>>   I *have* been listening to multiple developers and deployers with independent use cases, including RISC developers, as have other working group members.
>> 
> 
> Maybe you have. What I can say is that RISC is the only profile that presented a detailed use case document to drive requirements. It's concerns and use cases seem to be ignored constantly for a long time. Just saying how the situation looks from my perspective.

<ph>. This is not true. Backchannel logout has implementers and clear draft published. 

SCIM published its use cases to this group and also has an ID for it's events (expired). 

RISC has no published wg materials of its own. 

If we want to discuss non-functional, part of the problem is the presumption that RISC itself has consensus on its requirements. We do not because again risc has not published. I know because I am a sponsoring member participant. 
> 
>  
>>   Please try to focus discussion in productive ways on use cases, business value, engineering tradeoffs, and feedback from actual deployments.  I don’t want anyone to feel any ill will at the end of this process, simply because people may have disagreed about the best path forward in the short term.  Healthy disagreement about engineering and schedule tradeoffs is normal and listening to one another helps us all get to a better outcome than would have otherwise been achieved.
>> 
> 
> Perfect, we are on the same page.
> 
> With that in mind, can I ask you to spell out reasons in details? It helps me and others understand your reasoning and I will feel heard.
<ph> i believe we have at length
> 
> Also, I want to acknowledge that you do have a difficult job and I do appreciate that you want to keep the spec stable. I think it is very reasonable to push back on requests for major changes, but at the same time it is reasonable at times to take them into consideration.

<ph> I remained surprised the chairs found relevance to re-open the issue. Had you considered https://tools.ietf.org/html/draft-hunt-idevent-token-00 you would note that single event is where this work began. 

If we make this change we will have gone in circles without clear justification and have failed to move forward. IMO, this would compromise the consensus process given that most people want to finish. 

Also why are you strongly dismissing running code? This is a core principle of the ietf. The new proposal has no implementation nor evidence it addresses the so-called ambiguity issue.  See my other email. 

We have worked well in the past. I hope you don't wish to kill this effort with your passion. 

If the draft does go forward it will be rough consensus. I regret that. 

>> From: Marius Scurtescu [mailto:mscurtescu@google.com] 
>> Sent: Thursday, December 14, 2017 5:04 PM
>> To: M.Lizar@OCG <m.lizar@openconsentgroup.com>
>> Cc: Richard Backman, Annabelle <richanna@amazon.com>; William Denniss <wdenniss@google.com>; SecEvent <id-event@ietf.org>; Yaron Sheffer <yaronf.ietf@gmail.com>; Mike Jones <Michael.Jones@microsoft.com>; Morteza Ansari (moransar) <moransar@cisco.com>; Phil Hunt <phil.hunt@oracle.com>
>> 
>> 
>> Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending
>>  
>> 
>> Mark, this thread tackles a potential event subject claim and you mention structured event claim. I assume you meant structured subject claim.
>> 
>>  
>> 
>> Do you understand the current limitations of how subjects can be expressed? Are you sure that Consent Receipts can deal with these limitations? If not, then rushing the current SET and then working on a separate draft just for subject claims will overall result in an even longer delay. More than that, Consent Receipts and most other profiles will not be able to use only the SET spec, they will also need the delivery spec and the management api specs and at least the management api spec also has  a dependency on a subject claim. So again, rushing SET will not buy us much.
>> 
>>  
>> 
>> The only profile that depends only on SET and apparently does not care about a subject claim is back-channel logout. I understand that Mike wants to move forward but as an author I think he should take into consideration all feedback and all use cases.
>> 
>>  
>> 
>> We all want stable specs as soon as possible, but we want solid functional specs that cover a large number of use cases.
>> 
>>  
>> 
>> 
>> 
>> Marius
>> 
>>  
>> 
>> On Thu, Dec 14, 2017 at 4:47 PM, M.Lizar@OCG <m.lizar@openconsentgroup.com> wrote:
>> 
>> Consent receipts would like to use SETs once they're stable. 
>> 
>>  
>> 
>> Mark
>> 
>> 
>> 
>> 
>> On 14 Dec 2017, at 17:33, Richard Backman, Annabelle <richanna@amazon.com> wrote:
>> 
>>  
>> 
>> Neither of those documents makes any reference to SET. How do they depend on its finalization?
>> 
>>  
>> 
>> -- 
>> 
>> Annabelle Richard Backman
>> 
>> Amazon – Identity Services
>> 
>>  
>> 
>>  
>> 
>> From: Id-event <id-event-bounces@ietf.org> on behalf of "M.Lizar@OCG" <m.lizar@openconsentgroup.com>
>> Date: Thursday, December 14, 2017 at 1:14 PM
>> To: William Denniss <wdenniss@google.com>
>> Cc: Marius Scurtescu <mscurtescu@google.com>, SecEvent <id-event@ietf.org>, Yaron Sheffer <yaronf.ietf@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, "Morteza Ansari (moransar)" <moransar@cisco.com>, Phil Hunt <phil.hunt@oracle.com>
>> Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending
>> 
>>  
>> 
>> +1 - We would like to discourage delays in the completion of SETs to add a structured event claim.  The Consent Receipt v1.1 that is now finally in a 45 Day public IPR review at the Kantara initiative is aimed  at providing the content and format semantics for privacy transparency and compliance.   Other specs like the  COEL from OASIS, which use this same format, have now also just gone into 45 day public review. 
>> 
>>  
>> 
>> For us, its important to get this spec stable before the new GDPR laws become enforced in May
>> 
>>  
>> 
>> Mark 
>> 
>>  
>> 
>>  
>> 
>> On 8 Dec 2017, at 15:37, William Denniss <wdenniss@google.com> wrote:
>> 
>>  
>> 
>> I don't think we need to specify how profiles will use 'sub' in the event payload. +1 to Morteza's comment that profiles can specify the subject in the event payload as they see fit. The existing text reads well to me.
>> 
>>  
>> 
>>    sub  As defined by Section 4.1.2 [RFC7519], a String or URI value
>> 
>>       representing the principal or the subject of the SET.  This is
>> 
>>       usually the entity whose "state" was changed.  For example, an IP
>> 
>>       Address was added to a black list.  A URI representing a user
>> 
>>       resource that was modified.  A token identifier for a revoked
>> 
>>       token.  If used, the Profiling Specification SHOULD define the
>> 
>>       content and format semantics for the value.  This claim is
>> 
>>       OPTIONAL, as the principal for any given profile may already be
>> 
>>       identified without the inclusion of a subject claim.  Note that
>> 
>>       some SET profiles MAY choose to convey event subject information
>> 
>>       in the event payload (either using the "sub" member name or
>> 
>>       another name), particularly if the subject information is relative
>> 
>>       to issuer information that is also conveyed in the event payload,
>> 
>>       which may be the case for some identity SET profiles.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Fri, Dec 8, 2017 at 1:34 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>> 
>> That is a bit unfair. RISC is as important to me as the rest. 
>> 
>>  
>> 
>> You have commented you want pilots by end of year. That is what we are working towards. 
>> 
>> Phil
>> 
>> 
>> On Dec 7, 2017, at 8:02 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
>> 
>> On Thu, Dec 7, 2017 at 5:15 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>> 
>> Scim and backchannel do not need it. They would like to move on. 
>> 
>>  
>> 
>> Right. You and Mike are editors of the spec, are you making a spec just for the two of you?
>> 
>>  
>> 
>> How is SCIM pointing to the subject? Always using iss+sub? SCIM will never be in the situation where the subject issuer is different from the SET issuer?
>> 
>>  
>> 
>> Again, this thread is not asking for a major change, it is asking to add a claim name that can be used by profiles as an extension point. There is the question of alternative subject identifiers, so some discussion is necessary.
>> 
>>  
>> 
>> 
>> 
>> Phil
>> 
>> 
>> On Dec 7, 2017, at 4:56 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
>> 
>> On Thu, Dec 7, 2017 at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> 
>> Marius – you say that “it will slow down the SET spec, but that is unavoidable and very necessary. Implementations will have to wait for the subject claim spec anyhow.”
>> 
>>  
>> 
>> Both of these statements are incorrect.  Slowing down the SET spec is *totally avoidable* because any new event subject claim can be added via the JWT Claims Registry in a separate spec.  That’s what registries are intended to enable!
>> 
>>  
>> 
>> Most implementors will have to wait for the event subject claim as well, and they will be slowed down even more.
>> 
>>  
>> 
>>  
>> 
>> Also, implementations not using this new claim, such as OpenID Connect Back-Channel Logout, *will not have to wait*, because the existing working group spec already totally does the job.  It’s time for us to finish it!
>> 
>>  
>> 
>> How is back-channel affected in either case? It will not use a new event subject claim, so it does matter. Everyone else will be affected as stated above.
>> 
>>  
>> 
>>  
>> 
>> We should not block the SET spec, which is mature, on new work that can and should be decoupled, and is still in its formative stages.
>> 
>>  
>> 
>> Again, if it was mature we would not have all these threads. Using maturity as a reason to refuse feedback makes no sense.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>                                                        -- Mike
>> 
>>  
>> 
>> From: Marius Scurtescu [mailto:mscurtescu@google.com] 
>> Sent: Thursday, December 7, 2017 11:49 AM
>> To: Morteza Ansari (moransar) <moransar@cisco.com>
>> Cc: Phil Hunt <phil.hunt@oracle.com>; Mike Jones <Michael.Jones@microsoft.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; SecEvent <id-event@ietf.org>
>> 
>> 
>> Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending
>> 
>>  
>> 
>>  
>> 
>> Here is my comment on the original thread (not sure why was that thread split):
>> 
>>  
>> 
>> 
>> Defining an "event_subject" claim would help interop and add real value to the SET spec.
>> 
>>  
>> 
>> We also need a way to specif multiple alternative subjects. We talked about using a separate claim for that. Here is an example:
>> 
>>  
>> 
>> {
>> 
>>      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>> 
>>      "iss": "https://transmitter.example.com",
>> 
>>      "aud": [ "https://receiver.example.com" ],
>> 
>>      "iat": 1458496025,
>> 
>>      "event": {
>> 
>>        "event_type": "https://secevent.example.com/example_event",
>> 
>>        "event_subject": {
>> 
>>          "identifier_type": "urn:ietf:params:secevent:subject:email",
>> 
>>          "email": "user@example.com"
>> 
>>        },
>> 
>>        "event_subject_alt": [
>> 
>>          {
>> 
>>            "identifier_type": "urn:ietf:params:secevent:subject:connect",
>> 
>>            "iss": "https://idp.example.com",
>> 
>>            "sub": "abc123",
>> 
>>          },
>> 
>>          {
>> 
>>            "identifier_type": "urn:ietf:params:secevent:subject:phone",
>> 
>>            "phone_number": "+40-123-456-789",
>> 
>>          },
>> 
>>        ],
>> 
>>        "event_time": 1458492425,
>> 
>>        "claim_1": "foo",
>> 
>>        "claim_2": "bar"
>> 
>>      }
>> 
>>    }
>> 
>>  
>> 
>>  
>> 
>> Important note: the event_subject and event_subject_alt claims are orthogonal to the events vs event discussion, it can be applied to either.
>> 
>>  
>> 
>>  
>> 
>> I think this should be added to the current SET spec and not a separate spec. Yes, it will slow down the SET spec, but that is unavoidable and very necessary. Implementations will have to wait for the subject claim spec anyhow. The real questions speed question is this: will two specs be faster than adding to the existing one? And speed is not the only criteria. Defining some generic JWT spec to specify subjects will take a long time I am afraid, it is a much larger problem, let's not boil the ocean.
>> 
>>  
>> 
>> This new subject claim should probably be optional and back-channel logout should probably not be forced to use it. I am saying probably, since we don't want to put the cart before the horse.
>> 
>>  
>> 
>>  
>> 
>> 
>> 
>> Marius
>> 
>>  
>> 
>> On Thu, Dec 7, 2017 at 12:28 AM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
>> 
>> +1
>> 
>>  
>> 
>> Handling this as a future extension is the right approach. Phil’s last point is also a very good one as this might even help other JWT use cases if kept generic.
>> 
>>  
>> 
>>  
>> 
>> Cheers,
>> 
>> Morteza
>> 
>>  
>> 
>> From: Id-event <id-event-bounces@ietf.org> on behalf of Phil Hunt <phil.hunt@oracle.com>
>> Date: Tuesday, December 5, 2017 at 1:14 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, SecEvent <id-event@ietf.org>
>> Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending
>> 
>>  
>> 
>> I agree with Mike.
>> 
>>  
>> 
>> I raised the issue before, but there was little interest. If there is interest now, it would be best addressed as a separate specification.
>> 
>>  
>> 
>> Further to Mike’s comments, subject claims may be useful for other specification areas that use JWTs — so making it a separate specification has its advantages.
>> 
>>  
>> 
>> Phil
>> 
>>  
>> 
>> Oracle Corporation, Identity Cloud Services Architect
>> 
>> @independentid
>> 
>> www.independentid.com
>> 
>> phil.hunt@oracle.com
>> 
>>  
>> 
>> On Dec 5, 2017, at 12:50 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> 
>>  
>> 
>> I'm fine with the working group deciding to work on an optional event subject claim to be used by some profiles, should people want to do that, provided that doing so does not delay completion of the SET spec.  If pursued, this work should be in a separate specification, with the defined claim being registered in the IANA JWT Claims Registry- especially since some already deployed profiles, such as OpenID Connect Back-Channel Logout and I believe others, don't need it.
>> 
>>  
>> 
>> The idea of a structured event subject claim, while potentially useful in the future, is immature compared to the SET spec, and not yet informed by deployment experience.  Decoupling the SET and Event Subject work will enable us to finish the SET spec soon, while giving time for implementers to provide feedback on their needs for a structured subject claim based on their future deployment experiences.  This result would be the best of both worlds – a completed SET spec soon and a structured subject claim spec once there is data to validate that we’ve gotten it right for multiple profiles.
>> 
>>  
>> 
>> But to be clear, I am strongly opposed to trying to jam this new feature still that is still being designed into the already mature SET spec, which would certainly unnecessarily significantly delay its completion.
>> 
>>  
>> 
>>                                                                 -- Mike
>> 
>>  
>> 
>> -----Original Message-----
>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Yaron Sheffer
>> Sent: Sunday, December 3, 2017 9:39 AM
>> To: SecEvent <id-event@ietf.org>
>> Subject: [Id-event] Consensus :: Event Subject Claim - resending
>> 
>>  
>> 
>> Do we specify how a subject is included in a SET or let profiles define that?
>> 
>>  
>> 
>> The current draftdraft-ietf-secevent-token-03 <https://tools.ietf.org/html/draft-ietf-secevent-token-03>defines
>> 
>> the/sub/claim as an optional string or URI, with semantics left to the profile. This claim is placed in the SET envelope. No "subject" claim is defined inside the/event/object, which means that profiles are free to define such claims as they see fit.
>> 
>>  
>> 
>> Alternatively, we could have an/event_subject/claim inside the/event/object, with a "SHOULD" normative status.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> We will track results here: 
>> 
>> https://github.com/IETF-SecEvent/Drafts/issues/2
>> 
>> <https://github.com/IETF-SecEvent/Drafts/issues/2>
>> 
>>  
>> 
>> Discussion to be on the mail list as usual, not in the issue tracker!
>> 
>>  
>> 
>> _______________________________________________
>> 
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=
>> 
>>  
>> 
>> 
>> _______________________________________________
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qCsVU8GSrNishJH840WEp7RRVV5Qyt_dAFLnIxZdXrA&s=hWumbgAlx3vB4z_y8DRi4w6VEh7XVep0LAn9KBC5Ds0&e=
>> 
>> 
>> _______________________________________________
>> 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
>> 
>>  
>> 
>>  
>> 
>>  
>> 
> 