<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">eg Trust frameworks, Government Privacy certifications, Commercial contracts etc.</div><div class=""><br class=""></div><div class="">It might be worth considering having another signed object for this that could be inside or outside of the software statement.</div><div class=""><br class=""></div><div class="">They would need to be tied together by a key or redirect_uri for the client.</div><div class=""><br class=""></div><div class="">I could see the client presenting multiple attestations as part of it’s registration. </div><div class=""><br class=""></div><div class="">One from a privacy Trust framework and one from a Gov source.</div><div class=""><br class=""></div><div class="">For MODRNA including it as part of the software statement probably would work just fine.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Perhaps as a optimization if it is unsigned then it would inherit the signature of the enveloping software statement.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Aug 14, 2015, at 4:24 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta content="text/html; charset=utf-8" http-equiv="Content-Type" class=""><meta content="text/html; charset=utf-8" http-equiv="Content-Type" class=""><meta content="text/html; charset=utf-8" http-equiv="Content-Type" class=""><meta content="text/html; charset=utf-8" http-equiv="Content-Type" class=""><div bgcolor="#FFFFFF" text="#000000" class="">Hi George, <br class="">
<br class="">
the central authority will certainly sign the statement. <br class="">
<br class="">
kind regards, <br class="">
Torsten. <br class=""><br class=""><div class="gmail_quote">Am 13. August 2015 23:33:52 WESZ, schrieb George Fletcher <<a href="mailto:gffletch@aol.com" class="">gffletch@aol.com</a>>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font face="Helvetica, Arial, sans-serif" class="">Thanks for the background
Torsten! That makes sense. <br class="">
<br class="">
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.<br class="">
<br class="">
Thanks,<br class="">
George<br class="">
</font><br class="">
<div class="moz-cite-prefix">On 8/13/15 4:36 PM, Torsten Lodderstedt
wrote:<br class="">
</div>
<blockquote cite="mid:10C4117A-C00B-4AB4-9FC3-70C22514F5D4@lodderstedt.net" type="cite" class="">
Hi Georg, <br class="">
<br class="">
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. <br class="">
<br class="">
kind regards, <br class="">
Torsten. <br class="">
<br class="">
<div class="gmail_quote">Am 13. August 2015 12:20:55 MESZ, schrieb
George Fletcher <a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a>:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;"> <font face="Helvetica, Arial,
sans-serif" class="">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.<br class="">
<br class="">
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?<br class="">
<br class="">
Thanks,<br class="">
George<br class="">
</font><br class="">
<div class="moz-cite-prefix">On 8/12/15 2:37 PM, Torsten
Lodderstedt wrote:<br class="">
</div>
<blockquote cite="mid:55CB924E.8020104@lodderstedt.net" type="cite" class=""> I don't distinguish claims in the registration
request and in the software statement. It's just a different
"container".<br class="">
<br class="">
<div class="moz-cite-prefix">Am 12.08.2015 um 20:32 schrieb
George Fletcher:<br class="">
</div>
<blockquote cite="mid:55CB913F.5010102@aol.com" type="cite" class="">
<font face="Helvetica, Arial, sans-serif" class="">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 :)<br class="">
<br class="">
Thanks,<br class="">
George<br class="">
</font><br class="">
<div class="moz-cite-prefix">On 8/12/15 2:19 PM, Torsten
Lodderstedt wrote:<br class="">
</div>
<blockquote cite="mid:55CB8E3C.9020106@lodderstedt.net" type="cite" class="">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. <br class="">
<br class="">
Entitlement is given by the authority, which issued the
software statement, the RP wants to register with. <br class="">
<br class="">
Am 12.08.2015 um 01:07 schrieb John Bradley: <br class="">
<blockquote type="cite" class="">So these wold be default claims,
or a filter that prevents more than the listed claims
from coming back. <br class="">
<br class="">
How do you see this interacting with scopes? <br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Aug 11, 2015, at 8:32 AM,
Torsten Lodderstedt <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net></a>
wrote: <br class="">
<br class="">
Hi Mike, <br class="">
<br class="">
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. <br class="">
<br class="">
kind regards, <br class="">
Torsten. <br class="">
<br class="">
<br class="">
_______________________________________________ <br class="">
Openid-specs-ab mailing list <br class="">
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<br class="">
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
<br class="">
</blockquote>
</blockquote>
<br class="">
_______________________________________________ <br class="">
Openid-specs-ab mailing list <br class="">
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<br class="">
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
<br class="">
<br class="">
</blockquote>
<br class="">
<div class="moz-signature">-- <br class="">
<a moz-do-not-send="true" href="http://connect.me/gffletch" title="View full
card on Connect.Me" class=""><object moz-do-not-send="true" alt="George Fletcher" height="113" width="359" class="" data="cid:part1.09020401.04090500@aol.com" type="application/x-apple-msg-attachment"></object></a></div>
</blockquote>
<br class="">
</blockquote>
<br class="">
<div class="moz-signature">-- <br class="">
<a moz-do-not-send="true" href="http://connect.me/gffletch" title="View full card on Connect.Me" class=""><img moz-do-not-send="true" src="content://com.fsck.k9.attachmentprovider/43b3034d-50e7-4633-a511-8f32b542981a/1849/RAW" alt="George Fletcher" height="113" width="359" class=""></a></div>
</blockquote>
</div>
</blockquote>
<br class="">
<div class="moz-signature">-- <br class="">
<a href="http://connect.me/gffletch" title="View full card on
Connect.Me" class=""><img src="content://com.fsck.k9.attachmentprovider/43b3034d-50e7-4633-a511-8f32b542981a/1850/RAW" alt="George Fletcher" height="113" width="359" class=""></a></div>
</blockquote></div></div></div></blockquote></div><br class=""></div></body></html>