[WG-OTTO] OpenID note on software statement / client registration in OpenID Connect

[Mike Schwartz]

OTTO WG,

There is an interesting thread in the OpenID Connect mailing list. 
Perhaps we can discuss it in the meeting next week. It may be tangential 
to our work.

- Mike


----------------------------------------------------------------------

Message: 1
Date: Fri, 14 Aug 2015 20:19:52 +0000
 From: Mike Jones <Michael.Jones at microsoft.com>
To: John Bradley <ve7jtb at ve7jtb.com>, Torsten Lodderstedt
     <torsten at lodderstedt.net>
Cc: OpenId Connect List <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] "claims" in the Client Registration
     Spec?
Message-ID:
     
<BY2PR03MB4429E1859757CCED63AC02DF57C0 at BY2PR03MB442.namprd03.prod.outlook.com>

Content-Type: text/plain; charset="utf-8"

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.

I agree with this.  We should be looking at this comprehensively and not 
just taking a feature view.

                                                             -- Mike

 From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] 
On Behalf Of John Bradley
Sent: Friday, August 14, 2015 3:46 PM
To: Torsten Lodderstedt
Cc: OpenId Connect List
Subject: Re: [Openid-specs-ab] "claims" in the Client Registration Spec?

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.