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

[Marius Scurtescu <[e-mail]>]

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) <[e-mail]>
wrote:

> Ok. But you raised the concern. Are you withdrawing it?
>
> Phil
>
> On Oct 23, 2017, at 5:47 PM, Marius Scurtescu <[e-mail]>
> wrote:
>
> On Mon, Oct 23, 2017 at 4:15 PM, Phil Hunt <[e-mail]> wrote:
>
>> 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.
>>
>
> 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
>>
>> 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=>
>> [e-mail]
>>
>> On Oct 23, 2017, at 3:58 PM, Marius Scurtescu <[e-mail]>
>> wrote:
>>
>> 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 <[e-mail]> 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
>>> <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=>
>>> [e-mail]
>>>
>>> On Oct 23, 2017, at 2:38 PM, Marius Scurtescu <[e-mail]>
>>> 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 <[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__dat
>>>> 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= >).
>>>>    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=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.ietf.
>>>> org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZ
>>>> YR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjW
>>>> wlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuU
>>>> Y&s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&e= >
>>>> _______________________________________________
>>>> Id-event mailing list
>>>> [e-mail]
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>>>> f.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHv
>>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzj
>>>> WwlNKe4C_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.iet
>>>> f.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHv
>>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzj
>>>> WwlNKe4C_lLIGk&m=UUydIFEV9SQ_lw_LNE4lvS7pQLXEZEWA2F1i7bfAuUY
>>>> &s=jX1QgcFI8umtt8pEkthXa3uL_TsJINLVTXORUpSDnvA&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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=qgzi6hIQUdXUCZu3X2lrQFAdGZO2O9szzwPah2M8LX0&s=kr9e2Ob_q0g5BinjBOLJAjrZeWIcrCNx9O1jax-Bs8o&e=>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> Id-event mailing list
>> [e-mail]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivz
>> jWwlNKe4C_lLIGk&m=fDB9pNmWNg5BPXoRtaXXB1Iz_tq5wICJLi5itJHRai
>> 0&s=7M0OleTd4BpCbNMHkA9Vif8ucznK2XkdYp7wB0zI3N0&e=
>>
>>
>>
>