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

[Marius Scurtescu <[e-mail]>]

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 <[e-mail]> 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.
>
> 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 <[e-mail]>
> 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 <[e-mail] <
> mailto:[e-mail] <[e-mail]>>> 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=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= >).
>    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
>    [e-mail] <mailto:[e-mail] <[e-mail]>>
>    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
> [e-mail]
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>