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

n-sakimura n-sakimura at nri.co.jp
Thu Nov 28 01:53:33 UTC 2013


As you have quoted in the original mail, it is saying in section 5.1

The Request Object MAY be signed or unsigned (plaintext). When it is 
plaintext, this is indicated by use of thenonealgorithm[JWA] 
<http://openid.bitbucket.org/openid-connect-core-1_0.html#JWA>in the JWS 
header. If signed, the Request Object SHOULD contain the 
Claimsiss(issuer) andaud(audience) as members, with their semantics 
being as defined in theJWT 
<http://openid.bitbucket.org/openid-connect-core-1_0.html#JWT>[JWT] 
specification.

The SHOULD I stated is the one in the above sentence.

JWT further defines the semantics of the iss and aud as:


        4.1.1
        <http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-13#section-4.1.1>.
        "iss" (Issuer) Claim



    The "iss" (issuer) claim identifies the principal that issued the
    JWT.  The processing of this claim is generally application specific.
    The "iss" value is a case-sensitive string containing a StringOrURI
    value.  Use of this claim is OPTIONAL.


        4.1.3
        <http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-13#section-4.1.3>.
        "aud" (Audience) Claim



    The "aud" (audience) claim identifies the audiences that the JWT is
    intended for.  Each principal intended to process the JWT MUST
    identify itself with a value in audience claim.  If the principal
    processing the claim does not identify itself with a value in the
    "aud" claim, then the JWT MUST be rejected.  In the general case, the
    "aud" value is an array of case-sensitive strings, each containing a
    StringOrURI value.  In the special case when the JWT has one
    audience, the "aud" value MAY be a single case-sensitive string
    containing a StringOrURI value.  The interpretation of audience
    values is generally application specific.  Use of this claim is
    OPTIONAL.


They are accurate.

In OIDC context, the iss of the request object is the one who signed it.
It could be the client as well as a third party. I consider that even 
SHOULD is too strong if you want to indicate that the value would be the 
client id. At best, it would be a NOTE.

For aud, with the quolifier "if present", I would be OK to state that 
the value SHOULD be the issuer identifier of the OP.

Nat

(2013/11/28 9:47), Mike Jones wrote:
>
> Formerly, the spec said nothing about what these values were.  I can 
> live with making the "MUST"s "SHOULD"s, to accommodate the trust 
> framework case you described.  But I do think we need to say what the 
> normal values are.
>
> -- Mike
>
> *From:*sakimura at gmail.com [mailto:sakimura at gmail.com] *On Behalf Of 
> *Nat Sakimura
> *Sent:* Wednesday, November 27, 2013 3:48 PM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Signed request object issuer and audience
>
> 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 
> <mailto: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 issvalue MUST be the Client ID of the RP.
>
> The audvalue 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 <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>


-- 
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131128/1c0a73b6/attachment.html>


More information about the Openid-specs-ab mailing list