Re: [jose] 'aud' and 'iss' in JWE header

It doesn't seem harmful to me to have these parameters in there.  It just
seems like they won't be useful in a lot of cases.

Is there any particular reason that these fields have to be in the header
itself?  John Bradley had proposed earlier defining a separate container
for things that aren't necessarily of general use for JWE.

Perhaps we should set up a registry for JWE/JWS header parameters, with a
liberal inclusion policy (e.g., Specification Required), so that things
like this could be added easily.

--Richard

On Tue, Mar 26, 2013 at 1:57 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

> My other option would be to hack the 'kid' value to include both the 'iss'
> value and the 'aud' value so that a recipient would be able to determine if
> they are the audience and who the issuer is by cracking the 'kid' => but
> that seems like such a hack given that I have the ability to put the 'aud'
> and 'iss' in the header.
>
> Am I the only one that sees the value in having the 'aud' and 'iss' in the
> header for JWE?
>
> -- Dick
>
> On Mar 25, 2013, at 4:27 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> > 'iss' and 'aud' are not reserved header parameter names, so if I used
> them, then they would be private names subject to collision.
> >
> > Unless there is a reason why they should not be allowed, I'd like them
> to be reserved header parameter names so that their meaning is clear to an
> implementation or library. I would like to write my libraries to look at
> the header for those parameters if they are there.
> >
> > On Mar 25, 2013, at 4:19 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >
> >> That will be compliant.  The spec won't call out those particular
> properties from JWT.
> >>
> >> If you think that they should be called out as optional parameters that
> could be considered.  However that is not a open issue at this point.
> >>
> >> John B.
> >> On 2013-03-25, at 8:09 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> >>
> >>> Will that be compliant though? I would like to spec to say that I can
> optionally include those properties in the header of a JWE.
> >>>
> >>>
> >>> On Mar 25, 2013, at 4:02 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >>>
> >>>> Once the change to ignore additional elements in the header there is
> nothing to stop you from doing that.
> >>>>
> >>>> You make a good point about scoping the 'kid' to the 'iss'.
> >>>>
> >>>> John B.
> >>>>
> >>>> On 2013-03-25, at 7:53 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> >>>>
> >>>>> Hello everyone
> >>>>>
> >>>>> As I am implementing JOSE JWE, I would like to know who the 'iss'
> and 'aud' is. I am using symmetric, shared keys and the 'aud' party would
> like to know they really are the intended 'aud' and who the 'isa' is.
> Otherwise the 'iss' is inferred from the 'kid', and there is no guarantee
> that two 'iss' won't have the same 'kid' for different keys from different
> 'iss'.
> >>>>>
> >>>>> I don't see an issue with disclosure of who 'iss' and 'aud' are as
> any party able to intercept the token will have a pretty good idea of where
> it is coming from and where it is going to. Knowing the 'iss' and 'aud'
> allows the 'aud' to return an error before doing any crypto if the 'aud'
> does not match or if there is no 'kid' for the 'iss'.
> >>>>>
> >>>>> Is there a reason why I cannot have 'iss' and 'aud' in the header?
> >>>>>
> >>>>> This is not an issue with JWS since the payload is clear and the
> 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto.
> >>>>>
> >>>>> -- Dick
> >>>>> _______________________________________________
> >>>>> jose mailing list
> >>>>> jose@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/jose
> >>>>
> >>>
> >>
> >
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>