Subject: [Id-event] "aud" vs. receiver issue raised in WGLC

From: Phil Hunt <[email-masked]>
Date: Mon, 23 Oct 2017 10:57:51 -0700

All,

I am reviewing the previous feedback from WGLC and will be bringing up any unresolved issues for quick discussion/confirmation…

Following up on Marius and Henk’s comment, I am concerned that “aud” has a very specific meaning and is often tied to a security domain definition. We should not necessarily say this is the receiver though it often turns out to be. For example a RP (“aud”) has outsourced events processing to a third party (the so called receiver).

I am happy with the current claim set, but maybe some text explaining that a receiver does not have to be the aud is appropriate?  I don’t see any benefit to having a receiver claim as this could complicate processing more than its worth.

There are a few other comments in this thread, but this one seemed the most unresolved.

Phil

> On Aug 3, 2017, at 8:03 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hello,
> 
> to me, the "audience" claim seems to be a good choice here.
> 
> Viele Grüße,
> 
> Henk
> 
> On 08/02/2017 11:45 PM, Marius Scurtescu wrote:
>> The abstract mentions "issuer" and "receiver" in the last sentence. "receiver" does not sound right (that should be used in the context of a transmitter), but I don't have a better suggestion. Audience?
>> The last paragraph of section 1 mentions "subscriber". I think it should be either "receiver" or "audience".
>> The explanation for figure 1 states that the issuer denotes the transmitter. If the issuer and the transmitter are assumed to be the same entity, then the transmitter definition in section 1.2 should make that clear.
>> Figure 3, I think the "sub" claim should be nested in the event, next to the issuer that provides the correct context. The "iss" and "sub" definitions in 2.1 also touch on this, providing conflicting advice.
>> Section 2,1, definition of "nbf". The definition says that this is the event time. I see two problems:
>> - the name suggest "not before", not exactly the same as event time
>> - there can be multiple events
>> maybe this claim should be dropped?
>> Section 2.1, definition of "exp". Omitting this claim is the short term solution to the confusion issue. Why not mention that and that it SHOULD NOT be used?
>> Section 2.1, definition of "events". It states that all events must refer to the same logical event. Lately in discussions we reached the conclusion that all events in a SET should be defined in the same profile, which is a stronger requirement. I think this definition should mention that.
>> Regarding events and profiles. There was a proposal to add a new claim to uniquely identify the profile. I think we need to discuss that.
>> Figure 5. Maybe a signed example would be better, especially that the next paragraph mentions that signatures or encryption should be used.
>> Section 4.5, second paragraph. Mentions that "nonce" is also required, but that is not actually true. Id Tokens issued at the token endpoint for example will not have it. I suggest we drop the whole paragraph.
>> Marius
>> On Mon, Jul 31, 2017 at 1:40 PM, Yaron Sheffer <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>    This is to announce working group last call on this draft
>>    (https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e=>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e=> >).
>>    Please send your comments to the list. Even if you are perfectly
>>    happy with the draft, please let us know that you support its
>>    publication as-is by posting to the list.
>>    Because of the summer holidays, this last call is open for 3 weeks,
>>    until Aug. 21.
>>    Thanks,
>>         Dick and Yaron
>>    _______________________________________________
>>    Id-event mailing list
>>    [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=> >
>> _______________________________________________
>> Id-event mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=> 
> 
> _______________________________________________
> Id-event mailing list
> [email-masked] <mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=>

---

From: Mike Jones <[email-masked]>
Date: Mon, 23 Oct 2017 18:30:38 +0000

I am also happy with the current audience semantics.

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, October 23, 2017 10:58 AM
To: ID Events Mailing List <[email-masked]>
Subject: [Id-event] "aud" vs. receiver issue raised in WGLC

All,

Phil

On Aug 3, 2017, at 8:03 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Viele Grüße,

Henk

The abstract mentions "issuer" and "receiver" in the last sentence. "receiver" does not sound right (that should be used in the context of a transmitter), but I don't have a better suggestion. Audience?
The last paragraph of section 1 mentions "subscriber". I think it should be either "receiver" or "audience".
The explanation for figure 1 states that the issuer denotes the transmitter. If the issuer and the transmitter are assumed to be the same entity, then the transmitter definition in section 1.2 should make that clear.
Figure 3, I think the "sub" claim should be nested in the event, next to the issuer that provides the correct context. The "iss" and "sub" definitions in 2.1 also touch on this, providing conflicting advice.
Section 2,1, definition of "nbf". The definition says that this is the event time. I see two problems:
- the name suggest "not before", not exactly the same as event time
- there can be multiple events
maybe this claim should be dropped?
Section 2.1, definition of "exp". Omitting this claim is the short term solution to the confusion issue. Why not mention that and that it SHOULD NOT be used?
Section 2.1, definition of "events". It states that all events must refer to the same logical event. Lately in discussions we reached the conclusion that all events in a SET should be defined in the same profile, which is a stronger requirement. I think this definition should mention that.
Regarding events and profiles. There was a proposal to add a new claim to uniquely identify the profile. I think we need to discuss that.
Figure 5. Maybe a signed example would be better, especially that the next paragraph mentions that signatures or encryption should be used.
Section 4.5, second paragraph. Mentions that "nonce" is also required, but that is not actually true. Id Tokens issued at the token endpoint for example will not have it. I suggest we drop the whole paragraph.
Marius
On Mon, Jul 31, 2017 at 1:40 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
   This is to announce working group last call on this draft
   (https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e=     <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e= >).
   Please send your comments to the list. Even if you are perfectly
   happy with the draft, please let us know that you support its
   publication as-is by posting to the list.
   Because of the summer holidays, this last call is open for 3 weeks,
   until Aug. 21.
   Thanks,
        Dick and Yaron
   _______________________________________________
   Id-event mailing list
   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= >
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 23 Oct 2017 14:38:33 -0700

I think "aud" is perfectly fine.

IMO it should make no difference for the Transmitter that the event is
actually handled by an outsourced entity, the RP trusts that entity and the
event is generated and targeted to the RP and not to the current outsourced
processor.

Marius

On Mon, Oct 23, 2017 at 10:57 AM, Phil Hunt <[email-masked]> wrote:

>
> All,
>
> I am reviewing the previous feedback from WGLC and will be bringing up any
> unresolved issues for quick discussion/confirmation…
>
> Following up on Marius and Henk’s comment, I am concerned that “aud” has a
> very specific meaning and is often tied to a security domain definition. We
> should not necessarily say this is the receiver though it often turns out
> to be. For example a RP (“aud”) has outsourced events processing to a third
> party (the so called receiver).
>
> I am happy with the current claim set, but maybe some text explaining that
> a receiver does not have to be the aud is appropriate?  I don’t see any
> benefit to having a receiver claim as this could complicate processing more
> than its worth.
>
> On Aug 3, 2017, at 8:03 AM, Henk Birkholz <[email-masked]>
> wrote:
>
> Hello,
>
> The abstract mentions "issuer" and "receiver" in the last sentence.
> "receiver" does not sound right (that should be used in the context of a
> transmitter), but I don't have a better suggestion. Audience?
> The explanation for figure 1 states that the issuer denotes the
> transmitter. If the issuer and the transmitter are assumed to be the same
> entity, then the transmitter definition in section 1.2 should make that
> clear.
> Figure 3, I think the "sub" claim should be nested in the event, next to
> the issuer that provides the correct context. The "iss" and "sub"
> definitions in 2.1 also touch on this, providing conflicting advice.
> Section 2.1, definition of "exp". Omitting this claim is the short term
> solution to the confusion issue. Why not mention that and that it SHOULD
> NOT be used?
> Section 2.1, definition of "events". It states that all events must refer
> to the same logical event. Lately in discussions we reached the conclusion
> that all events in a SET should be defined in the same profile, which is a
> stronger requirement. I think this definition should mention that.
> Regarding events and profiles. There was a proposal to add a new claim to
> uniquely identify the profile. I think we need to discuss that.
> Figure 5. Maybe a signed example would be better, especially that the next
> paragraph mentions that signatures or encryption should be used.
> Section 4.5, second paragraph. Mentions that "nonce" is also required, but
> that is not actually true. Id Tokens issued at the token endpoint for
> example will not have it. I suggest we drop the whole paragraph.
> Marius
> On Mon, Jul 31, 2017 at 1:40 PM, Yaron Sheffer <[email-masked] <
> mailto:[email-masked] <[email-masked]>>> wrote:
>    (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwIGaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_
> LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfj
> qT99u5-Ojw4Fw&e=     <https://urldefense.proofpoint.com/v2/
> url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-
> 2Dsecevent-2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y
> TpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_
> lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfj
> qT99u5-Ojw4Fw&e= >).
>    [email-masked] <mailto:[email-masked] <[email-masked]>>
>    https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_
> LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_
> TsJINLVTXORUpSDnvA&e=     <https://urldefense.proofpoint.
> com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-
> 2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_
> LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_
> TsJINLVTXORUpSDnvA&e= >
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_
> LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_
> TsJINLVTXORUpSDnvA&e=
>
>
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_
> LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_
> TsJINLVTXORUpSDnvA&e=
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 23 Oct 2017 15:55:39 -0700

It seems reasonable to further clarify that the definition of a receiver could be improved.

I propose to change from:
   Event Receiver
      An Event Receiver is an entity that receives SETs through some
      distribution method.

To:
   Event Receiver
      An Event Receiver is an entity that receives SETs through some
      distribution method. An Event Receiver MAY be a different
      entity than that described by the “aud” claim.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Oct 23, 2017, at 2:38 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> IMO it should make no difference for the Transmitter that the event is actually handled by an outsourced entity, the RP trusts that entity and the event is generated and targeted to the RP and not to the current outsourced processor.
> 
> Marius
> 
> On Mon, Oct 23, 2017 at 10:57 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> All,
> 
> 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=qgzi6hIQUdXUCZu3X2lrQFAdGZO2O9szzwPah2M8LX0&s=kr9e2Ob_q0g5BinjBOLJAjrZeWIcrCNx9O1jax-Bs8o&e=>
> 
>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 23 Oct 2017 15:58:28 -0700

I think "aud" should point to the Receiver, the outsourcing is irrelevant.

Nothing needs to change here IMO.

Marius

On Mon, Oct 23, 2017 at 3:55 PM, Phil Hunt <[email-masked]> wrote:

> www.independentid.com
> [email-masked]
>> I am reviewing the previous feedback from WGLC and will be bringing up
>> any unresolved issues for quick discussion/confirmation…
>>
>> Following up on Marius and Henk’s comment, I am concerned that “aud” has
>> a very specific meaning and is often tied to a security domain definition.
>> We should not necessarily say this is the receiver though it often turns
>> out to be. For example a RP (“aud”) has outsourced events processing to a
>> third party (the so called receiver).
>>
>> I am happy with the current claim set, but maybe some text explaining
>> that a receiver does not have to be the aud is appropriate?  I don’t see
>> any benefit to having a receiver claim as this could complicate processing
>> more than its worth.
>>
>> On Aug 3, 2017, at 8:03 AM, Henk Birkholz <[email-masked].
>> de> wrote:
>>
>> Hello,
>>
>> Figure 5. Maybe a signed example would be better, especially that the
>> next paragraph mentions that signatures or encryption should be used.
>> Section 4.5, second paragraph. Mentions that "nonce" is also required,
>> but that is not actually true. Id Tokens issued at the token endpoint for
>>    (https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=
>> DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5b
>> iRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4
>> lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e=
>>      <https://urldefense.proofpoint.com/v2/url?
>> u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dseceven
>> t-2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057
>> SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
>> UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9M
>> d1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e= >).
>> ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCg
>> aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPE
>> ivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=
>> jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=     <https://
>> urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
>> mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8P
>> QcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe
>> 4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=
>> jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHv
>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivz
>> jWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuU
>> Y&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHv
>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivz
>> jWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuU
>> Y&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=
>>
>>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=qgzi6hIQUdXUCZu3X2lrQFAdGZO2O9szzwPah2M8LX0&s=kr9e2Ob_q0g5BinjBOLJAjrZeWIcrCNx9O1jax-Bs8o&e=>
>>
>>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 23 Oct 2017 16:15:11 -0700

It’s quite relevant to those with distributed architectures.

If an Event Stream requires that SETs need to be encrypted (using JWE), the SETs needs to be encrypted so the “receiver" can read it.  Regardless, “aud” should be interpreted by the traditional JWT method which suggests the security domain the event is for.  For example, a web site relying party does not have the capability to process (or issue) events itself (eg. because of a distributed architecture). The relying party assigns another entity the role of Event Receiver (or Transmitter).  

The problem being that If the “set” is encrypted for “aud” then only the “aud” entity can read the SET which will make it impossible to for another server to handle or worse, it would require sharing of private keys. 

Phil

> On Oct 23, 2017, at 3:58 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> On Mon, Oct 23, 2017 at 3:55 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai0&s=Ee7RsPFKzheWNvOz1Ut9gCvs_2bw0DE6GEeg-S0KMyE&e=>[email-masked] <mailto:[email-masked]>
> 
>> On Oct 23, 2017, at 2:38 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai0&s=7M0OleTd4BpCbNMHkA9Vif8ucznK2XkdYp7wB0zI3N0&e=

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Oct 2017 00:04:05 +0000

Thanks for the useful review, Nat.  Proposed resolutions are inline below.

FYI, Annabelle Backman and I sat down last week during the Internet Identity Workshop (IIW) and read through all the WGLC comments.  The series of replies to come contains proposed resolutions we discussed.

From: Nat Sakimura [mailto:[email-masked]]
Sent: Wednesday, August 2, 2017 10:07 AM
To: M.Lizar@OCG <[email-masked]>; Mike Jones <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

Thanks, it looks generally good. I had only three small nits.

1) "MUST NOT" in the introduction.
---------------------------------------------------
I feel that it is better to have this MUST NOT in the main text. The introduction often is skipped by a reader.

Agreed:  Propose changing “MUST NOT” to “cannot”.

2) Potentially missing "defined in " in Section 2 the first bullet
------------------------------------------------------------------------------------------------------
There seems to be missing "defined in" in the sentence "the JWT Token Claims Registry Section 10.1".

I’ll change this reference to [IANA.JWT.Claims] with target https://www.iana.org/assignments/jwt/jwt.xhtml#claims.

3) Issuer validation
----------------------------------
I am not sure how to do an issuer validation when using unsecured JWT.
Adding more explanation would be beneficial.

I propose adding this additional sentence to the paragraph you referenced:
“Likewise if the profile allows (or requires) that the JWT be unsecured, the means by which the integrity of the JWT is ensured MUST be specified.”

Best,

Nat

                                                                Thanks,
                                                                -- Mike

On Wed, Aug 2, 2017 at 1:18 AM M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>> wrote:
+1 on existing text .

Agree the document is ready to publish

- Mark

On 31 Jul 2017, at 16:53, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

I believe that the specification is ready to publish as-is.  It already meets the needs of the known use cases and is in production use.

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Monday, July 31, 2017 1:40 PM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] WG Last Call for draft-ietf-secevent-token-02

This is to announce working group last call on this draft (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/).

Please send your comments to the list. Even if you are perfectly happy with the draft, please let us know that you support its publication as-is by posting to the list.

Because of the summer holidays, this last call is open for 3 weeks, until Aug. 21.

Thanks,
    Dick and Yaron
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Oct 2017 00:04:39 +0000

Thanks for the detailed review, Annabelle, and for sitting down with me in person last week to go over it.  Proposed resolutions follow in-line.

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Wednesday, August 2, 2017 11:43 AM
To: M.Lizar@OCG <[email-masked]>; Mike Jones <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

Thanks for all the work on this! It was my understanding that there was an open item from Prague regarding whether to explicitly declare the events’ profiling specification in the SET. Has this been discussed further, or do we still need to close on it?

I have several comments/questions on the current draft:

  1.  “Profile Specification” vs. “Profiling Specification”
There are a handful of instances of the former that need to be changed to the latter, to match the term as defined in section 1.2:
     *   In the “sub” definition in section 1.2
     *   In section 3
     *   In section 4.2

I think we should uniformly go with the term “Profiling Specification”, as you suggest.

  1.  Note regarding Subject Issuer vs. SET Issuer
The note regarding the potential for Subject and SET Issuer mismatch (in the “iss” definition in section 1.2) is I think more prescriptive than intended. As written, it mandates placing the Subject’s Issuer in an “iss” value within the event payload, but does not define a format or structure for this value. The logical format – that of the “iss” JWT claim – may or may not be appropriate, depending on the nature of the event and its Subject. I suggest removing this note and covering this concern elsewhere (see #4 below, re: Subject Identification).
(You were actually referring to Section 2.1.)  As we discussed, if the logical issuer for the SET doesn’t fit the JWT “iss” string syntax, it’s perfectly reasonable to define a different claim and its syntax that meets the application’s needs.  The “Note” part also doesn’t dictate that the “sub” claim name be used.  We could add the parenthetical remark “(either using the “iss” member name or another name)” before the first comma in the note, to make this point clear, if you think that would address your concern.

  1.  Explicit Typing of SETs
I suggest removing the text “if the SET could be used in an application context in which it could be confused with other kinds of JWTs” from the first paragraph of section 2.2, making the secevent+jwt typ header mandatory to implement for all SETs. This conditional is impossible to evaluate, as new types of JWTs will be introduced over time. Just considering existing JWTs, it is a lot to ask for Profiling Spec authors to fully examine the contents and usage of every existing JWT. Mandating use of typ for SETs takes this load off of Profiling Spec authors and insures that future specs have a consistent, reliable way to defend against JWT type confusion.
As we discussed, I’m reluctant to remove the clause because there is already this strong language at the end of the paragraph: “This MUST be included if the SET could be used in an application context in which it could be confused with other kinds of JWTs.”  So the default behavior is already the one you want.

  1.  Requirements for SET Profiles: Subject Identification
I suggest adding text along the lines of “Profiling Specifications MUST define for each of their events how the Subject is identified in the SET, as well as how to address conflicts the event Subject’s Issuer and the SET Issuer if applicable. It is NOT RECOMMENDED for Profiling Specifications to use the “sub” claim in cases where the Subject is not globally unique and has a different Issuer from the SET itself.”
I’m OK adding something along those lines.

  1.  Guidance for Signing SETs
The text in the last paragraph of section 4.1 is unclear to me. It seems to suggest that it is safe to send unsigned JWTs over a channel that lacks transport-layer security, so long as requests include a bearer token or use Basic Authentication. Am I misreading this? It seems counter to the guidance given earlier in the same section.
Good catch.  In fact the plain reading of the first half of the sentence is self-contradictory.  As we discussed, let’s simplify this to “Unless integrity of the JWT is ensured by other means, it MUST be signed using JWS…”

  1.  Distinguishing SETs from other kinds of JWTs
The last sentence of the first paragraph of section 4.7 seems impossible to me. Profiling Specifications cannot be solely responsible for ensuring incompatibility with all future JWT profiles. They can at best ensure incompatibility with existing JWT profiles and be compatible with a standard mechanism by which future JWT profiles may ensure incompatibility (e.g. the “secevent+jwt” typ header). It may be enough to strike the “(or other)” text from this sentence.
The second paragraph (beginning “The most direct way”) was written before we had explicit typing.  As we discussed, I propose to reorder paragraphs 2 and 3, changing explicit typing to be “The most direct way” and mutually exclusive validation logic to be “Another way”.  That puts the emphasis where it should be, at this juncture in the development of the specification.

--
Annabelle Richard Backman
Identity Services

                                                                Thanks again!
                                                                -- Mike

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 1, 2017 at 9:17 AM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

+1 on existing text .

- Mark

                                                                -- Mike

Thanks,
    Dick and Yaron

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Oct 2017 00:05:10 +0000

Thanks for the useful review comments, Marius.  The proposed resolutions that Annabelle and I discussed in-person are as follows.

From: Id-event [mailto:[email-masked]] On Behalf Of Marius Scurtescu
Sent: Wednesday, August 2, 2017 2:46 PM
To: Yaron Sheffer <[email-masked]>
Cc: SecEvent <[email-masked]>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

JWT [RFC 7519], JWS, JWE, etc. uniformly use the term “recipient” for this concept.  I believe we should do the same.

“recipients” seems right here again, both for consistency sake, and because the plain English meaning matches the intended semantics.

I believe that the “transmitter” is intended to be able to be different than the “issuer”.  JWT uses the term “issuer” and not “transmitter”, FYI.  I believe that some of the uses of “transmitter” should actually be “issuer” – in particular this needs to be changed “An "iss" claim, denoting the Event Transmitter.”  An “Event Issuer” definition probably needs to be also added.  I’ll take a crack and normalizing this terminology usage, both to match JWT, and to make the “issuer” / “transmitter” distinction clear.

OK, in this case, I think I’m fine with the proposed change.

At least Annabelle and I agreed with you that dropping this claim description from the SET makes sense, as it’s described usage is currently kind of a hack.  (“nbf” could still be used by some profiles in its usual JWT manner without the SET spec saying anything about it.)  We propose replacing it with the “toe” (time of event) claim described in the thread “[Id-event] Replacing "nbf" claim with a new "toe" claim”.

It’s said that it should not be used because it’s one of the most commonly used claims in other JWTs and this paragraph gives us a place to describe the rationale for not using it in SET profiles.

I’m OK adding a statement that they should all be from profiles with compatible claims usage, which I think is what you’re actually after.

As discussed on the list, the problem with adding a new “profile” claim is that it duplicates information already derivable from the event URIs.  This can lead to error conditions that are otherwise impossible, because inconsistencies can arise.  Also, per the previous reply events need to be from compatible profiles – not necessarily the same profile – and so a singleton “profile” claim wouldn’t actually work in the general case.

Unsigned keeps the draft shorter. ;-)

Good catch.  It should really be qualified to say “it would not contain the correct "nonce" claim value for the ID Token to be accepted in contexts for which substitution is possible”.

                                                                Thanks again, Marius!
                                                                -- Mike
Marius

On Mon, Jul 31, 2017 at 1:40 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
This is to announce working group last call on this draft (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/).

Thanks,
    Dick and Yaron

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 23 Oct 2017 17:47:25 -0700

On Mon, Oct 23, 2017 at 4:15 PM, Phil Hunt <[email-masked]> wrote:

> If an Event Stream requires that SETs need to be encrypted (using JWE),
> the SETs needs to be encrypted so the “receiver" can read it.  Regardless,
> “aud” should be interpreted by the traditional JWT method which suggests
> the security domain the event is for.  For example, a web site relying
> party does not have the capability to process (or issue) events itself (eg.
> because of a distributed architecture). The relying party assigns another
> entity the role of Event Receiver (or Transmitter).
>
> The problem being that If the “set” is encrypted for “aud” then only the
> “aud” entity can read the SET which will make it impossible to for another
> server to handle or worse, it would require sharing of private keys.
>

The RP controls the configuration of the stream, so they can specify an
endpoint that belongs to the outsourced receiver and they can also specify
an encryption key that is controlled by the outsourced receiver. The RP
does not need access to the private key at all.

I still think it is irrelevant to the transmitter, or to this spec. I agree
it is totally relevant for the RP,

>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai0&s=Ee7RsPFKzheWNvOz1Ut9gCvs_2bw0DE6GEeg-S0KMyE&e=>
>> [email-masked]
>>
>>> Section 2.1, definition of "events". It states that all events must
>>> refer to the same logical event. Lately in discussions we reached the
>>> conclusion that all events in a SET should be defined in the same profile,
>>> which is a stronger requirement. I think this definition should mention
>>> that.
>>> Regarding events and profiles. There was a proposal to add a new claim
>>> to uniquely identify the profile. I think we need to discuss that.
>>>    (https://urldefense.proofpoint.com/v2/url?u=https-3A__dat
>>> atracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=D
>>> wIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5bi
>>> RrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4l
>>> vS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e=
>>>      <https://urldefense.proofpoint.com/v2/url?u
>>> =https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-
>>> 2Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057Sb
>>> K10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV
>>> 9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl
>>> 6cxjlKfjqT99u5-Ojw4Fw&e= >).
>>> ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCga
>>> WHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEi
>>> vzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfA
>>> uUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=     <ht
>>> tps://urldefense.proofpoint.com/v2/url?u=https-3A__www.
>>> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0
>>> FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXE
>>> ZEWA2F1i7bfAuUY&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= >
>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzj
>>> WwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY
>>> &s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=
>>>
>>>
>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzj
>>> WwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY
>>> &s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e=
>>>
>>>
>>>
>>>
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_
> tq5wICJLi5itJHRai0&s=7M0OleTd4BpCbNMHkA9Vif8ucznK2XkdYp7wB0zI3N0&e=
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 23 Oct 2017 17:49:40 -0700

Ok. But you raised the concern. Are you withdrawing it?

Phil

> On Oct 23, 2017, at 5:47 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> The RP controls the configuration of the stream, so they can specify an endpoint that belongs to the outsourced receiver and they can also specify an encryption key that is controlled by the outsourced receiver. The RP does not need access to the private key at all.
> 
> I still think it is irrelevant to the transmitter, or to this spec. I agree it is totally relevant for the RP,
> 
> 
>> 
>> Phil
>> 
>>>>>>> On Aug 3, 2017, at 8:03 AM, Henk Birkholz <[email-masked]> wrote:
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>>> On Mon, Jul 31, 2017 at 1:40 PM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 23 Oct 2017 17:52:49 -0700

I raised a wording issue, not sure if it still applies:

"The abstract mentions "issuer" and "receiver" in the last sentence.
"receiver" does not sound right (that should be used in the context of a
transmitter), but I don't have a better suggestion. Audience?
The last paragraph of section 1 mentions "subscriber". I think it should be
either "receiver" or "audience"."

Marius

On Mon, Oct 23, 2017 at 5:49 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=CB-Hkcxglh-YNhXysOrrok_4zCGDYpxX49Xsuqtk5xM&s=yLs1cTxnvZUXAqt72qLGSJmz0X3EKVE6yNBJ0nsVUgo&e=>
>> [email-masked]
>>
>>>> Following up on Marius and Henk’s comment, I am concerned that “aud”
>>>> has a very specific meaning and is often tied to a security domain
>>>> definition. We should not necessarily say this is the receiver though it
>>>> often turns out to be. For example a RP (“aud”) has outsourced events
>>>> processing to a third party (the so called receiver).
>>>>
>>>> The last paragraph of section 1 mentions "subscriber". I think it
>>>> should be either "receiver" or "audience".
>>>> Figure 3, I think the "sub" claim should be nested in the event, next
>>>> to the issuer that provides the correct context. The "iss" and "sub"
>>>> atracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwI
>>>> GaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRr
>>>> KugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS
>>>> 7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6cxjlKfjqT99u5-Ojw4Fw&e=
>>>>     <https://urldefense.proofpoint.com/v2/url?u=
>>>> https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2
>>>> Dtoken_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK
>>>> 10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=UUydIFEV9
>>>> SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY&s=9SIT98RlAb1C9Md1W54IRl6
>>>> cxjlKfjqT99u5-Ojw4Fw&e= >).
>>>> tps://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.
>>>> org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZ
>>>> YR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjW
>>>> wlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuU
>>>> Y&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= >
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> jWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai
>> 0&s=7M0OleTd4BpCbNMHkA9Vif8ucznK2XkdYp7wB0zI3N0&e=
>>
>>
>>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 23 Oct 2017 18:45:26 -0700

Ok. I will do search replace on subscriber as they should all be receiver. 

Thks

Phil

> On Oct 23, 2017, at 5:52 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> "The abstract mentions "issuer" and "receiver" in the last sentence. "receiver" does not sound right (that should be used in the context of a transmitter), but I don't have a better suggestion. Audience?
> The last paragraph of section 1 mentions "subscriber". I think it should be either "receiver" or "audience"."
> 
> 
> 
> Marius
> 
>> On Mon, Oct 23, 2017 at 5:49 PM, Phil Hunt (IDM) <[email-masked]> wrote:

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Oct 2017 03:08:19 +0000

See one of my other my other replies. The term should be “recipient” for JWT/JWS, etc. consistency.

From: Phil Hunt (IDM)<mailto:[email-masked]>
Sent: Monday, October 23, 2017 6:45 PM
To: Marius Scurtescu<mailto:[email-masked]>
Cc: ID Events Mailing List<mailto:[email-masked]>
Subject: Re: [Id-event] "aud" vs. receiver issue raised in WGLC

Thks

Phil

On Oct 23, 2017, at 5:52 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Marius

On Mon, Oct 23, 2017 at 5:49 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
Ok. But you raised the concern. Are you withdrawing it?

Phil

On Oct 23, 2017, at 5:47 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Oct 23, 2017 at 4:15 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
It’s quite relevant to those with distributed architectures.

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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=CB-Hkcxglh-YNhXysOrrok_4zCGDYpxX49Xsuqtk5xM&s=yLs1cTxnvZUXAqt72qLGSJmz0X3EKVE6yNBJ0nsVUgo&e=>
[email-masked]<mailto:[email-masked]>

On Oct 23, 2017, at 3:58 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Marius

On Mon, Oct 23, 2017 at 3:55 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
It seems reasonable to further clarify that the definition of a receiver could be improved.

   Event Receiver

To:

   Event Receiver

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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai0&s=Ee7RsPFKzheWNvOz1Ut9gCvs_2bw0DE6GEeg-S0KMyE&e=>
[email-masked]<mailto:[email-masked]>

On Oct 23, 2017, at 2:38 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Marius

On Mon, Oct 23, 2017 at 10:57 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

All,

Phil

Hello,

Viele Grüße,

Henk

_______________________________________________
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=qgzi6hIQUdXUCZu3X2lrQFAdGZO2O9szzwPah2M8LX0&s=kr9e2Ob_q0g5BinjBOLJAjrZeWIcrCNx9O1jax-Bs8o&e=>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 23 Oct 2017 21:00:39 -0700

Mike,

The group originally requested change from publisher/subscriber to Event Transmitter and Event Receiver.

Regarding “consistency” between specs, I can’t find any definitive use of the term recipient in RFC7159, 7515, or 7523.  Am I missing something? I only found this paragraph:
> Note:  No "charset" parameter is defined for this registration.
>       Adding one really has no effect on compliant recipients.

Are we bike-shedding here? 

Phil

> On Oct 23, 2017, at 8:08 PM, Mike Jones <[email-masked]> wrote:
> 
> From: Phil Hunt (IDM) <mailto:[email-masked]>
> To: Marius Scurtescu <mailto:[email-masked]>
> Cc: ID Events Mailing List <mailto:[email-masked]>
> On Oct 23, 2017, at 5:52 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Mon, Oct 23, 2017 at 5:49 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>> On Oct 23, 2017, at 5:47 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Mon, Oct 23, 2017 at 4:15 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=CB-Hkcxglh-YNhXysOrrok_4zCGDYpxX49Xsuqtk5xM&s=yLs1cTxnvZUXAqt72qLGSJmz0X3EKVE6yNBJ0nsVUgo&e=>[email-masked] <mailto:[email-masked]>
>>>> On Oct 23, 2017, at 3:58 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai0&s=7M0OleTd4BpCbNMHkA9Vif8ucznK2XkdYp7wB0zI3N0&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai0&s=7M0OleTd4BpCbNMHkA9Vif8ucznK2XkdYp7wB0zI3N0&e=>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 24 Oct 2017 09:01:27 -0500

> Unsigned keeps the draft shorter. ;-)

That justification sounds like a joke, especially with the smiley.

In-document examples are used to give guidance to the reader, including
implicit guidance; I would strongly prefer for there to be examples that
actually describe the desired/expected common deployment scenario, to
subtly reiterate the expected case.

-Ben

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Oct 2017 18:54:39 +0000

https://tools.ietf.org/html/rfc7519#section-4.1.3:

4.1.3<https://tools.ietf.org/html/rfc7519#section-4.1.3>.  "aud" (Audience) Claim
   The "aud" (audience) claim identifies the recipients that the JWT is
   intended for.

There’s a bunch of other places where the term “recipient” occurs.  Previous inconsistences in JWT were pointed out during late WG reviews and addressed using the current terminology, which is part of why I remember this at all.

My point of view is that reviewers noticed inconsistent usage of terminology during WGLC, so we should try to address that.  SET doesn’t exist in a vacuum – it’s a profile of JWT, so to the extent that SET uses concepts that JWT already has names for, we should use the same names unless there are compelling reasons not to.

It may be bike-shedding, but in my experience, if we don’t address inconsistencies now, they will be pointed out to us again during IETF-wide review – possibly by Gen-Art, possibly by Sec-Dir, possibly by our AD, or possibly by individual reviewers – and if not then, by the RFC Editor.  Better to fix these things now, rather than let them linger and generate more objections and delays.

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, October 23, 2017 9:01 PM
To: Mike Jones <[email-masked]>
Cc: Marius Scurtescu <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] "aud" vs. receiver issue raised in WGLC

Mike,

Phil

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

On Oct 23, 2017, at 8:08 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

Thks

Phil

Marius

Phil

Phil

Marius

   Event Receiver

      distribution method.

To:

   Event Receiver

Phil

Marius

All,

Phil

Hello,

Viele Grüße,

Henk

---

From: Phil Hunt <[email-masked]>
Date: Tue, 24 Oct 2017 11:59:51 -0700

I stand corrected.  Yesterday my browser wasn’t showing no matches, and yet today it is. Weird.

I think as long as SET is consistent on Receiver, we’re probably good - meaning get rid of the remaining “subscriber” term.

Phil

> On Oct 24, 2017, at 11:54 AM, Mike Jones <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/rfc7519#section-4.1.3 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.3&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=zDjEgJvZeb4lVQNz1NbQT2pBNfKrowDq-2L0vKRmx7s&s=eXrB41SaogcZSrldajoknOKzzvuga-wE40fm7UdF4OM&e=>:
>  
>  <>4.1.3 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.3&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=zDjEgJvZeb4lVQNz1NbQT2pBNfKrowDq-2L0vKRmx7s&s=eXrB41SaogcZSrldajoknOKzzvuga-wE40fm7UdF4OM&e=>.  "aud" (Audience) Claim
> From: Phil Hunt [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>; ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=zDjEgJvZeb4lVQNz1NbQT2pBNfKrowDq-2L0vKRmx7s&s=gdHmXVJK_L6-6qkhvmdjy1VbfjGHvO6P4M-S3k_NHCI&e=>
> [email-masked] <mailto:[email-masked]>
>  
> On Oct 23, 2017, at 8:08 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>  
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=CB-Hkcxglh-YNhXysOrrok_4zCGDYpxX49Xsuqtk5xM&s=yLs1cTxnvZUXAqt72qLGSJmz0X3EKVE6yNBJ0nsVUgo&e=>
> [email-masked] <mailto:[email-masked]>
>  
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai0&s=Ee7RsPFKzheWNvOz1Ut9gCvs_2bw0DE6GEeg-S0KMyE&e=>
> [email-masked] <mailto:[email-masked]>
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=zDjEgJvZeb4lVQNz1NbQT2pBNfKrowDq-2L0vKRmx7s&s=DYiok-rItKjqJocoDkvX-5ccOQU1Q56gFaiip8X1fRA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=zDjEgJvZeb4lVQNz1NbQT2pBNfKrowDq-2L0vKRmx7s&s=DYiok-rItKjqJocoDkvX-5ccOQU1Q56gFaiip8X1fRA&e=>