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

[Luke Camery <[e-mail]>]

The arguments on this thread seem to focus around the delay that adding a
subject claim will cause. This seems illogical to me because no profiles,
let alone running code, can be finalized until this question is answered.
We're asking to do this work *once* across all profiles rather than *n
times*. This seems more likely to expedite than delay. In addition, the
management API will be delayed until the subject claim takes shape at
whatever level (profile, SET, or somewhere in between) meaning that the
blocking dependency still exists.

We have as much interest as anyone in getting this out the door. Google has
several engineers working on implementation and we cannot finish
implementation without a clear idea for subject. Throwing SET over the
fence without subject doesn't accomplish this work, it just kicks the can
down the road.


On Fri, Dec 15, 2017 at 2:28 PM Marius Scurtescu <[e-mail]>
wrote:

> On Fri, Dec 15, 2017 at 10:19 AM, Phil Hunt <[e-mail]> wrote:
>
>> Comments in line.
>>
>> Phil
>>
>> On Dec 15, 2017, at 9:07 AM, Marius Scurtescu <[e-mail]>
>> wrote:
>>
>> On Thu, Dec 14, 2017 at 6:05 PM, Mike Jones <[e-mail]>
>> 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.
>>
>
> Happy to look a use case document for back-channel logout. For what I
> understand it is a very simple use case. The constant argument I hear is
> that everything works for back-channel logout, and while that is a good
> thing I also don't think it is enough.
>
>
>>
>> SCIM published its use cases to this group and also has an ID for it's
>> events (expired).
>>
>
> From what I remember the SCIM use cases were very high level, which makes
> them hard to drive any requirements. But I can be wrong, can you please
> point to the latest doc?
>
>
>>
>> RISC has no published wg materials of its own.
>>
>
> What's that supposed to mean? RISC presented detailed use cases and they
> are tracked in an I-D.
>
>
>>
>> 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.
>>
>
> Not published what and where? Yes, of course it is work in progress and
> there are lots of open issues. Not sure where are you going with this.
>
>
>>
>>
>>
>>>   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
>>
>
> From where I stand what I see is answers like "works for back-channel
> logout" or "great reasons". Please don't take this personally, but use it
> as feedback to understand why we might have a disconnect.
>
>
>>
>> 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.
>>
>
> I am providing feedback as an early implementor, so yes, I do care about
> running code. I kept saying this over and over, not sure why are you
> lecturing me on this subject.
>
>
>> We have worked well in the past. I hope you don't wish to kill this
>> effort with your passion.
>>
>
> Same here. Not trying to kill anything, hoping for a working group where
> there is real collaboration. I understand that you see it different, but
> the way I see it is that there is no collaboration and that most efforts to
> improve the specs are constantly blocked.
>
>
>> If the draft does go forward it will be rough consensus. I regret that.
>>
>
> Not sure I understand?
>
>
>>
>> *From:* Marius Scurtescu [mailto:[e-mail]]
>>> *Sent:* Thursday, December 14, 2017 5:04 PM
>>> *To:* M.Lizar@OCG <[e-mail]>
>>> *Cc:* Richard Backman, Annabelle <[e-mail]>; William Denniss
>>> <[e-mail]>; SecEvent <[e-mail]>; Yaron Sheffer <
>>> [e-mail]>; Mike Jones <[e-mail]>;
>>> Morteza Ansari (moransar) <[e-mail]>; Phil Hunt <
>>> [e-mail]>
>>>
>>> *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 <
>>> [e-mail]> wrote:
>>>
>>> Consent receipts would like to use SETs once they're stable.
>>>
>>>
>>>
>>> Mark
>>>
>>>
>>>
>>> On 14 Dec 2017, at 17:33, Richard Backman, Annabelle <
>>> [e-mail]> 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 <[e-mail]> on behalf of "M.Lizar@OCG"
>>> <[e-mail]>
>>> *Date: *Thursday, December 14, 2017 at 1:14 PM
>>> *To: *William Denniss <[e-mail]>
>>> *Cc: *Marius Scurtescu <[e-mail]>, SecEvent <
>>> [e-mail]>, Yaron Sheffer <[e-mail]>, Mike Jones <
>>> [e-mail]>, "Morteza Ansari (moransar)" <
>>> [e-mail]>, Phil Hunt <[e-mail]>
>>> *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
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__kantarainitiative.org_confluence_download_attachments_76447870_Consent-2520Receipt-2520Specification-25201-5F1-5F0-2520DRAFT-25206.docx-3Fversion-3D1-26modificationDate-3D1511151270000-26api-3Dv2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4wH1gymoEq326ZCD687i7fB5qwH-VLvczq8pAdkoRMY&s=PPhowssGLzzU4Dhl21Ao1B11pt25VrdE5V3GBmemdhw&e=> 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
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.oasis-2Dopen.org_coel_COEL_v1.0_csprd02_COEL-2Dv1.0-2Dcsprd02.pdf&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4wH1gymoEq326ZCD687i7fB5qwH-VLvczq8pAdkoRMY&s=Q-OouVtbxlEv3EzV5l9cLfwo4aOtwEbcsBi0UGRZQUI&e=> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>> wrote:
>>>
>>> On Thu, Dec 7, 2017 at 5:15 PM, Phil Hunt <[e-mail]> 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 <[e-mail]>
>>> wrote:
>>>
>>> On Thu, Dec 7, 2017 at 11:54 AM, Mike Jones <[e-mail]>
>>> 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:[e-mail]]
>>> *Sent:* Thursday, December 7, 2017 11:49 AM
>>> *To:* Morteza Ansari (moransar) <[e-mail]>
>>> *Cc:* Phil Hunt <[e-mail]>; Mike Jones <
>>> [e-mail]>; Yaron Sheffer <[e-mail]>;
>>> SecEvent <[e-mail]>
>>>
>>>
>>> *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": "[e-mail]"
>>>
>>>        },
>>>
>>>        "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": "[phone]",
>>>
>>>          },
>>>
>>>        ],
>>>
>>>        "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) <
>>> [e-mail]> 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 <[e-mail]> on behalf of Phil Hunt <
>>> [e-mail]>
>>> *Date: *Tuesday, December 5, 2017 at 1:14 PM
>>> *To: *Mike Jones <[e-mail]>
>>> *Cc: *Yaron Sheffer <[e-mail]>, SecEvent <[e-mail]
>>> >
>>> *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
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM&s=337h9ahCqEnkyo3wKcMrEVWEEXSZ5HswVurVvXBet9k&e=>
>>>
>>> [e-mail]
>>>
>>>
>>>
>>> On Dec 5, 2017, at 12:50 PM, Mike Jones <[e-mail]>
>>> 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
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=>-
>>> especially since some already deployed profiles, such as OpenID Connect
>>> Back-Channel Logout
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=>
>>>  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:[e-mail]
>>> <[e-mail]>] On Behalf Of Yaron Sheffer
>>> Sent: Sunday, December 3, 2017 9:39 AM
>>> To: SecEvent <[e-mail]>
>>> 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
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=>
>>> >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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=>
>>>
>>> <https://github.com/IETF-SecEvent/Drafts/issues/2
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=>
>>> >
>>>
>>>
>>>
>>> Discussion to be on the mail list as usual, not in the issue tracker!
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Id-event mailing list
>>>
>>> [e-mail]
>>>
>>> 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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=>
>>>
>>> _______________________________________________
>>> Id-event mailing list
>>> [e-mail]
>>>
>>> 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
>>> [e-mail]
>>> 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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM&s=o3JZgDc6WNNqDqIl_RSgzBmT4KEget2lduea5cfV5fA&e=>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Id-event mailing list
>>> [e-mail]
>>>
>>>
>>> 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
>>> [e-mail]
>>> 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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4wH1gymoEq326ZCD687i7fB5qwH-VLvczq8pAdkoRMY&s=ORE8sYOjURtA5iE1Sm2WvJwile2FMTPSvsJPzhvre8M&e=>
>>>
>>>
>>>
>>> _______________________________________________
>>> Id-event mailing list
>>> [e-mail]
>>> 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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4wH1gymoEq326ZCD687i7fB5qwH-VLvczq8pAdkoRMY&s=ORE8sYOjURtA5iE1Sm2WvJwile2FMTPSvsJPzhvre8M&e=>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>



-- 

*  •  **Luke Camery*
*  •  *Associate Product Manager
*  •  *Federated Identity