[Openid-specs-ab] Signed request object issuer and audience

Nat Sakimura nat at sakimura.org
Wed Nov 27 23:47:49 UTC 2013


I oppose to the change to MUST.

I can easily think of a scenario such that a trust framework operator (TFO)
signs the request object and the relying parties who are the member of the
trust framework uses it. In this case, the iss will be the TFO, and aud
would not be there, as the IdPs are undetermined at the time of signing.
The client_id will be Client ID then. That's why it was a SHOULD. It was a
deliberate decision. We should let the deployment profiles define these and
not to be too prescriptive.


2013/11/28 Mike Jones <Michael.Jones at microsoft.com>

>  Core currently says:
>
> If signed, the Request Object SHOULD contain the Claims iss (issuer) and
> aud (audience) as members, with their semantics being as defined in the
> JWT [JWT] specification.
>
>
>
> In response to Justin’s review comment that the “iss” and “aud” values
> should be specified, I started to write this:
>
> The iss value MUST be the Client ID of the RP.
>
> The aud value MUST be or include the OP's Issuer Identifier URL.
>
>
>
> However, I then realized that the Client is already being communicated in
> the “client_id” request parameter, so also having it in the “iss” claim
> would be redundant.
>
>
>
> I therefore propose that we explicitly say that an “iss” claim is not
> needed, since the Client ID identifies the request’s originator, and
> require that the “client_id” parameter be present in all Request Objects.
> I would still add the sentence about the “aud” value.
>
>
>
> Do people agree with this approach?  I agree with Justin that we do need
> to specify what values to use.
>
>
>
>                                                                 -- Mike
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131128/88e27f81/attachment.html>


More information about the Openid-specs-ab mailing list