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

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 <phil.hunt@oracle.com> wrote:

> 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
> phil.hunt@oracle.com
>
> On Oct 23, 2017, at 2:38 PM, Marius Scurtescu <mscurtescu@google.com>
> wrote:
>
> 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 <phil.hunt@oracle.com> 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 <henk.birkholz@sit.fraunhofer.
>> de> 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 <yaronf.ietf@gmail.com <
>> mailto:yaronf.ietf@gmail.com <yaronf.ietf@gmail.com>>> 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=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= >).
>>    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
>>    Id-event@ietf.org <mailto:Id-event@ietf.org <Id-event@ietf.org>>
>>    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
>> 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= >
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org
>> 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=
>>
>>
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org
>> 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=
>>
>>
>>
>>
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org
>> https://www.ietf.org/mailman/listinfo/id-event
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=qgzi6hIQUdXUCZu3X2lrQFAdGZO2O9szzwPah2M8LX0&s=kr9e2Ob_q0g5BinjBOLJAjrZeWIcrCNx9O1jax-Bs8o&e=>
>>
>>
>
>