Sorry for not responding to this mail earlier. Somehow, it went to Gmail spam box...<div><br></div><div>My suggestion to this is to first separate the claims endpoint registration issues and claims request/response. The later is much easier to tackle than the former. I would suggest that we leave the former out of scope for the time being - i.e., let it be a manual process for now. </div>
<div><br></div><div>For the later: </div><div><br></div><div>Ask claims by including the following in the request. </div><div><br></div><div>- General Purpose Statement</div><div>- Requester description (ID, Display Name)</div>
<div>- Jurisdiction of the requester</div><div>- ToS text / Link</div><div>- List of claims. </div><div><br></div><div>e.g., </div><div><br></div><div>{</div><div> "purpose":"To reserve the room at the hotel premise. To contact you with regard to this booking. ", </div>
<div> "requester":"Ex Hotel Holdings, KK.", </div><div> "jurisdiction":"JP",</div><div> "tos":"<a href="https://hotel.example.com/tos.html">https://hotel.example.com/tos.html</a>",</div>
<div> "claims":{</div><div> "schema":"ABC_Default", </div><div> "email":"", </div><div> "phone":"", </div><div> "name":"", </div>
<div> "address":""</div><div> }</div><div>}</div><div><br></div><div>Response would then look like: </div><div><br></div><div>{</div><div> "email":"alice@wonderla.nd", </div>
<div> "phone":"+81(3)1234-5678",</div><div> "name":"Alice de Wonderland", </div><div> "address":{</div><div> "endpoint":"<a href="https://checkout.example.com/">https://checkout.example.com/</a>",</div>
<div> "access_token":"afjs0fjd"}</div><div>}</div><div><br></div><div>OR</div><div><br></div><div><div>{</div><div> "email":"alice@wonderla.nd", </div><div> "phone":"+81(3)1234-5678",</div>
<div> "name":"Alice de Wonderland", </div><div> "access_tokens":[ </div><div> {</div><div> "claim_type":"address",</div><div> "endpoint":"<a href="https://checkout.example.com/">https://checkout.example.com/</a>",</div>
<div> "access_token":"afjs0fjd"</div><div> }</div><div> ]</div><div>}</div></div><div> </div><div>=nat<br><br><div class="gmail_quote">On Sat, Apr 23, 2011 at 6:03 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">There was much discussion in the most recent call about where we fit<br>
the UserInfoEndpoint, the ClaimsEndpoint, etc.<br>
<br>
The current proposal is to have the UserInfoEndpoint return user<br>
attributes as asserted by the Identity Provider/Server and have a<br>
separate endpoint that can be queried about claims that the IDP has<br>
aggregated. Chuck provided a concrete example in use by SalesForce,<br>
and there are also some industry efforts to use address claims issued<br>
by national entities in various countries.<br>
<br>
If the claims and services are to be obtained through 4th parties<br>
(i.e., not aggregated by the IDP but directly fetched from other<br>
parties) then how do we discover where to find the services/claim<br>
providers (and probably obtain a token for them at the same time)?<br>
<br>
I am not sure yet that we have a proposal that is both simple enough<br>
and flexible enough to satisfy known use cases. A possible topic of<br>
discussion for next meeting?<br>
<font color="#888888"><br>
--<br>
--Breno<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>
</font></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>