[Openid-specs-ab] "claims" in the Client Registration Spec?

John Bradley ve7jtb at ve7jtb.com
Fri Aug 14 19:45:32 UTC 2015


I suspect that given the privacy environment and trust frameworks there might be multiple sources of 3rd party signers that would enable a IdP to release attributes.

eg Trust frameworks,  Government Privacy certifications, Commercial contracts etc.

It might be worth considering having another signed object for this that could be inside or outside of the software statement.

They would need to be tied together by a key or redirect_uri for the client.

I could see the client presenting multiple attestations as part of it’s registration.  

One from a privacy Trust framework and one from a Gov source.

For MODRNA including it as part of the software statement probably would work just fine.

However from a overall design point of view we may want to allow 3rd party signed privacy/attribute attestations outside the software statement.   They are like a software statement but more specific.

This would be a signed JWT with an issuer and some sort of client identifier along with the trust framework or specific attributes being granted.

Perhaps as a optimization if it is unsigned then it would inherit the signature of the enveloping software statement.

I just have a feeling that this is a larger question around how 3rd parry attestations like belonging to a federation are included in registration information.

John B.


> On Aug 14, 2015, at 4:24 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
> Hi George, 
> 
> the central authority will certainly sign the statement. 
> 
> kind regards, 
> Torsten. 
> 
> Am 13. August 2015 23:33:52 WESZ, schrieb George Fletcher <gffletch at aol.com>:
> Thanks for the background Torsten! That makes sense. 
> 
> It still seems to me that if the claims are authorized by the central entity, then they need to be "signed" by the central entity so that the OP knows the RP didn't just put whatever they want in the list. As "trust frameworks" mature, I think this will be a more common use case.
> 
> Thanks,
> George
> 
> On 8/13/15 4:36 PM, Torsten Lodderstedt wrote:
>> Hi Georg, 
>> 
>> our assumption in MODRNA/Mobile Connect is that developers/partners register with a certain mobile operator or a central entity (provided by GSMA) and gets access to a number of OPs (provided by different mobile operators). Given this assumptions, an OP belonging to this ecosystem will trust software statements issued by the respective entities. So OPs effectively outsource partner validation and approval. This will require common standards agreed among all members of the ecosystem. 
>> 
>> kind regards, 
>> Torsten. 
>> 
>> Am 13. August 2015 12:20:55 MESZ, schrieb George Fletcher <gffletch at aol.com> <mailto:gffletch at aol.com>:
>> Agreed it's a different container... but to me the semantics of the container matter. The software statement is likely signed by a third party while the registration parameters (while maybe signed) are kind of "self asserted". As an AS, what I really need to know is "who" is making the request and then base the entitled claims on that more so than what's presented.
>> 
>> Would you want to delegate to a partner the ability for them to specify which claims their clients can obtain without any "oversight" from the AS perspective?
>> 
>> Thanks,
>> George
>> 
>> On 8/12/15 2:37 PM, Torsten Lodderstedt wrote:
>>> I don't distinguish claims in the registration request and in the software statement. It's just a different "container".
>>> 
>>> Am 12.08.2015 um 20:32 schrieb George Fletcher:
>>>> If these are claims the RP is entitled to receive, how does the AS verify that claim? Shouldn't that data be in the Software Statement rather than in the client reg parameters? I'm probably missing something :)
>>>> 
>>>> Thanks,
>>>> George
>>>> 
>>>> On 8/12/15 2:19 PM, Torsten Lodderstedt wrote:
>>>>> good point. I would assume this is the list of claims the RP is entitled to get access to. I think it doesn't matter whether the RP asks for the claim via scopes or claims parameter. 
>>>>> 
>>>>> Entitlement is given by the authority, which issued the software statement, the RP wants to register with. 
>>>>> 
>>>>> Am 12.08.2015 um 01:07 schrieb John Bradley: 
>>>>>> So these wold be default claims, or a filter that prevents more than the listed claims from coming back. 
>>>>>> 
>>>>>> How do you see this interacting with scopes? 
>>>>>> 
>>>>>> 
>>>>>>> On Aug 11, 2015, at 8:32 AM, Torsten Lodderstedt <torsten at lodderstedt.net> <mailto:torsten at lodderstedt.net> wrote: 
>>>>>>> 
>>>>>>> Hi Mike, 
>>>>>>> 
>>>>>>> as you are in the process of producing eratas of the OIDC specs, I would like to raise a question regarding client registration we came up with in the MODRNA WG. Right now, the RP may restrict itself to certain grant and response types. We see the need to do the same for claims. Would you consider it a reasonable enhancement of the Client Registration spec to add something like "claims" to the registration spec? I consider it complementary to "claims_supported" as specified in the discovery spec. 
>>>>>>> 
>>>>>>> kind regards, 
>>>>>>> Torsten. 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________ 
>>>>>>> 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 <http://lists.openid.net/mailman/listinfo/openid-specs-ab> 
>>>>> 
>>>>> _______________________________________________ 
>>>>> 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 <http://lists.openid.net/mailman/listinfo/openid-specs-ab> 
>>>>> 
>>>> 
>>>> -- 
>>>>  <http://connect.me/gffletch>
>> 
>> -- 
>>  <http://connect.me/gffletch>
> -- 
>  <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150814/3f896400/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150814/3f896400/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list