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

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:phil.hunt@oracle.com]
Sent: Monday, October 23, 2017 9:01 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Marius Scurtescu <mscurtescu@google.com>; ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] "aud" vs. receiver issue raised in WGLC

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

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<http://www.independentid.com>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>

On Oct 23, 2017, at 8:08 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:

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

From: Phil Hunt (IDM)<mailto:phil.hunt@oracle.com>
Sent: Monday, October 23, 2017 6:45 PM
To: Marius Scurtescu<mailto:mscurtescu@google.com>
Cc: ID Events Mailing List<mailto:id-event@ietf.org>
Subject: Re: [Id-event] "aud" vs. receiver issue raised in WGLC

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 <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:
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) <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> wrote:
Ok. But you raised the concern. Are you withdrawing it?

Phil

On Oct 23, 2017, at 5:47 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:
On Mon, Oct 23, 2017 at 4:15 PM, Phil Hunt <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> 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=>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>

On Oct 23, 2017, at 3:58 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> 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 <phil.hunt@oracle.com<mailto: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<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=>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>

On Oct 23, 2017, at 2:38 PM, Marius Scurtescu <mscurtescu@google.com<mailto: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<mailto: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<mailto: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> <mailto: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=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
   Id-event@ietf.org<mailto:Id-event@ietf.org> <mailto:Id-event@ietf.org>
   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
Id-event@ietf.org<mailto:Id-event@ietf.org>
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
Id-event@ietf.org<mailto:Id-event@ietf.org>
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
Id-event@ietf.org<mailto: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=>

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
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=