I would like to amend the definition of 'cid' from token requester to token assignee, or the licensed/registered user of the token. JWT can be generic credential without respect to the protocol associated in obtaining it, so the above definition is better. <div>
<br></div><div>Actually, it was my homework to send the 'cid' proposal to OAuth list... I will do so later today. </div><div><br></div><div>Nat<br><br><div class="gmail_quote">On Wed, Dec 19, 2012 at 10:17 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we were to allow multiple audiences in a OIDC id_token it raises the question of how a client requests additional audiences and what it means to a client that receives a id token from that contains multiple audiences.<br>
There are also UI issues to consider around what consent the user is asked for.<br>
<br>
This overlaps with the google use case where the requester is identified in a separate claim.<br>
<br>
It may be a useful thing to indicate the actual requester of the JWT when there are multiple audiences.<br>
<br>
Allowing for a client to get a token that can be presented as part of an implicit flow to a third party with them as the audience opens up a security hole.<br>
<br>
I would be OK if we allow multiple audiences in the ID_token where the client ID of the requester is identified, as long as we do not allow tokens with multiple audiences in the implicit flow.<br>
<br>
So the normal case would be aud as a literal and the 'cid' is implicitly the same as 'aud'.<br>
<br>
If 'aud' and 'cid' differ then the 'aud' is an array of one or more values, and cid is the identifier of the token requestor.<br>
<br>
Then the id_token could be used in an assertion flow though I would prefer that cid have some linking to the client making the assertion flow request. perhaps there is a way to do that using a proof of possession key.<br>
<br>
Without proof of possession it is not really any worse than a single AS with multiple RS via scopes. The UI at the authorization server is the hardest part.<br>
<br>
You are being asked to grant client X a assertion granting it permission to access service y on host foo.<br>
<br>
The id_token probably needs to contain some sort of scope info for the target AS to make a decision on.<br>
<br>
>From a engineering perspective I like it. From an explaining it perspective it complicates things.<br>
<br>
John B.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 2012-12-18, at 9:01 PM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>> wrote:<br>
<br>
> BTW Justin, I got focused on other aspect of all this and forgot that<br>
> I wanted to ask you what (assuming aud and prn/sub/who/etc work out)<br>
> this exchange actually looked like? The JWT Assertion is designed for<br>
> the case of trading a JWT for an access token but it sounds like you<br>
> are using it to get an id token? Is that in place of the access token<br>
> or does it supplement it? Do you send an openid scope in the request?<br>
> Just curious really...<br>
><br>
> On Fri, Dec 14, 2012 at 3:40 PM, Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:<br>
>> You are correct. I hadn't caught that, but it does state in JWT Assertions:<br>
>><br>
>> The JWT MUST contain an aud (audience) claim containing a URI reference that<br>
>> identifies the authorization server, or the service provider principal<br>
>> entity of its controlling domain, as an intended audience. The token<br>
>> endpoint URL of the authorization server MAY be used as an acceptable value<br>
>> for an aud element. The authorization server MUST verify that it is an<br>
>> intended audience for the JWT.<br>
>><br>
>><br>
>> Which doesn't leave much wiggle room for the OIDC interpretation. Between<br>
>> this an 'prn', maybe this is a different kind of assertion claim, then? An<br>
>> id-token assertion grant type?<br>
>><br>
>> -- Justin<br>
>><br>
>><br>
>> On 12/14/2012 04:51 PM, Brian Campbell wrote:<br>
>><br>
>> I believe the current wording of the specs would prohibit that.<br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Dec 14, 2012 at 2:10 PM, Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:<br>
>>><br>
>>> My original idea is for the Client to use the JWT Assertion flow with a<br>
>>> current id_token to refresh it and get a new id_token. This goes back to the<br>
>>> session management proposal linked to within the issue. In this case, the<br>
>>> audience for the token really *is* the client, and an AS will need to look<br>
>>> for that.<br>
>>><br>
>>> -- Justin<br>
>>><br>
>>><br>
>>> On 12/14/2012 04:04 PM, Brian Campbell wrote:<br>
>>><br>
>>> I had a comment/question related to the below comment on issue 687 but not<br>
>>> really related to the issue itself. So figured the list would be the best<br>
>>> forum.<br>
>>><br>
>>> Regarding the potential use of an ID Token as an assertion in the OAuth<br>
>>> JWT Assertion Profile - aren't the requirements around the "aud" claim also<br>
>>> potentially a problem?<br>
>>><br>
>>> Connect says the aud of an ID Token "MUST be the OAuth 2.0 client_id of<br>
>>> the Client." While the OAuth JWT Assertion Profile is a little more flexible<br>
>>> but basically says the aud must identify the AS or its controlling entity.<br>
>>> Doesn't this imply that an ID Token could only really be used to get an<br>
>>> access token within the scope of the client to whom it was sent in the first<br>
>>> place? Which doesn't seem very useful. Or is it?<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Dec 13, 2012 at 5:23 PM, Michael Jones<br>
>>> <<a href="mailto:issues-reply@bitbucket.org">issues-reply@bitbucket.org</a>> wrote:<br>
>>>><br>
>>>> --- you can reply above this line ---<br>
>>>><br>
>>>> Issue 687: Messages - Add 'prn' claim to id_token to support JWT<br>
>>>> Assertion<br>
>>>><br>
>>>> <a href="https://bitbucket.org/openid/connect/issue/687/messages-add-prn-claim-to-id_token-to" target="_blank">https://bitbucket.org/openid/connect/issue/687/messages-add-prn-claim-to-id_token-to</a><br>
>>>><br>
>>>> Michael Jones:<br>
>>>><br>
>>>><br>
>>>> I agree that it would be a shame, architecturally, if we can't use an ID<br>
>>>> Token as a assertion in a way that complies with the OAuth JWT Assertion<br>
>>>> Profile. I believe we need to address this.<br>
>>>><br>
>>>> There are few ways to do this, as I see it:<br>
>>>><br>
>>>> 1. Add "prn" to the ID Token. Upside: Simple. Downsides: Wastes<br>
>>>> space through duplication of data; potential interop problem where not<br>
>>>> everyone duplicates or uses the information in the same way.<br>
>>>><br>
>>>> 2. Replace "user_id" with "prn" in the ID Token. Downside: Less<br>
>>>> mnemonic than user_id. Upside: simple.<br>
>>>><br>
>>>> 3. Modify the OAuth JWT Assertion Profile to allow the subject to be<br>
>>>> identified by a claim other than "prn" - possibly explicitly calling out<br>
>>>> "user_id". Upside: would work. Downside: Codifies inconsistency.<br>
>>>><br>
>>>> 4. Replace both "user_id" and "prn" with a different claim in both<br>
>>>> specs. Candidates include "id" and "sub".<br>
>>>><br>
>>>> Let's make this a topic for Monday's call.<br>
>>>><br>
>>>><br>
>>>> --<br>
>>>><br>
>>>> This is an issue notification from <a href="http://bitbucket.org" target="_blank">bitbucket.org</a>. You are receiving<br>
>>>> this either because you are the owner of the issue, or you are<br>
>>>> following the issue.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Openid-specs-ab mailing list<br>
>>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>>><br>
>>><br>
>><br>
>><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
<br>
</div>