<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">In principal nothing stops the claims being added to the user info_endpoint they are already URI named so there will not be a collision. <div><br></div><div>If there are archetectural reasons to separate them that is fine, use the distributed claims, or some combination.</div><div><br></div><div>A separate endpoint would allow getting them in XML or some other format if that was required as well.</div><div><br></div><div>John B.<br><div><div>On 2011-12-14, at 10:45 PM, Allen Tom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Roland,<div><br></div><div>I believe that it's OK to add more attributes to the user-info endpoint, so rather than creating a new eduPerson endpoint, why not just extend the user-info endpoint?</div><div><br></div><div>
Allen</div><div><br><br><div class="gmail_quote">On Wed, Dec 14, 2011 at 1:34 PM, Roland Hedberg <span dir="ltr"><<a href="mailto:roland.hedberg@adm.umu.se">roland.hedberg@adm.umu.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It was quite obvious that we for instance needed more and more varied identity information.<br>
So the (crazy?) idea came up that we would define a new endpoint beside the user-info endpoint, the eduPerson endpoint.<br>
Ideas about group/scim/authz endpoints also surfaced.<br>
<br></blockquote></div></div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>