<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Out of curiosity, beyond the email discussion below what are the primary metadata needs around the other major (PoCo) fields?<div><br></div><div>Speaking to the use-cases I work off of here at PBS, I'm primarily concerned about emails being verified (and a signup date is also useful) and am most inclined to trust the OP (especially if it were a white-listed or otherwise vetted iDP).</div><div><br></div><div>Jonathan</div><div><br></div><div><br></div><div><div>On Dec 8, 2009, at 2:17 PM, Chris Messina wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Is it worth looking at how Facebook handles the passing of profile data? Or is their architecture/use case different?<br><br><div><a href="http://wiki.developers.facebook.com/index.php/Users.getInfo">http://wiki.developers.facebook.com/index.php/Users.getInfo</a></div> <div><br><div class="gmail_quote">On Tue, Dec 8, 2009 at 11:08 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;"> <div class="im">On Tue, Dec 8, 2009 at 11:01 AM, John Panzer <<a href="mailto:jpanzer@google.com">jpanzer@google.com</a>> wrote:<br> > For "one-time" URLs, you'd probably want to allow for retries for a short<br> > period (or just allow it to be accessed for say 5m) which would have<br> > approximately the same level of protection.<br> > You could also imagine long-lived capabilities along the lines of OAuth<br> > tokens that allow RPs to repeatedly refresh the data as needed. (Better of<br> > course if they can subscribe to changes, but that's an implementation detail<br> > and definitely a separate spec.)<br> > Given that AX already supports requesting URL-valued data (e.g., profile<br> > photos) I think this just comes down to defining a fairly complicated data<br> > type for AX and passing a URL around.<br> <br> </div>A more lightweight alternative is to adopt an 'artifact' mode where<br> most of the OpenID assertion (request and response) can be passed in<br> the backchannel. That is a bit more difficult to implement but easier<br> to spec (because the existing URLs can be used) and more general<br> (compacts all extensions, not only AX).<br> <div class="im"><br> > --<br> > John Panzer / Google<br> > <a href="mailto:jpanzer@google.com">jpanzer@google.com</a> / <a href="http://abstractioneer.org" target="_blank">abstractioneer.org</a> / @jpanzer<br> ><br> ><br> ><br> > On Tue, Dec 8, 2009 at 10:57 AM, Peter Watkins <<a href="mailto:peterw@tux.org">peterw@tux.org</a>> wrote:<br> >><br> >> On Tue, Dec 08, 2009 at 10:32:12AM -0800, John Panzer wrote:<br> >><br> >> > provide to RPs. If you send an endpoint URL to the RP instead of the<br> >> > information itself, the RP can then retrieve it via a backchannel (and<br> >> > cache<br> >> > it). If you have private data, use a capability URL with a token that<br> >> > allows read-only access.<br> >><br> >> Exactly. OpenID requests and responses are very chatty, and backchannel<br> >> URLs could be an easy way to get around the 2k GET limit (the cost of<br> >> course being additional time needed to make the additional HTTP requests).<br> >><br> >> I don't see any reason for backchannel URLs to be requested multiple<br> >> times,<br> >> so in addition to a request or response using strongly random nonces in<br> >> the backchannel URLs, the backchannel URLs should be very short-lived,<br> >> probably each side "SHOULD" allow a URL to be requested only once, and<br> >> throw a 403/404 for subsequent requests.<br> >><br> >> Is there any draft of AX using backchannel URLs?<br> >><br> >> -Peter<br> ><br> ><br> </div>> _______________________________________________<br> > specs mailing list<br> > <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br> > <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br> ><br> ><br> <br> <br> <br> --<br> --Breno<br> <br> +1 (650) 214-1007 desk<br> +1 (408) 212-0135 (Grand Central)<br> MTV-41-3 : 383-A<br> PST (GMT-8) / PDT(GMT-7)<br> _______________________________________________<br> specs mailing list<br> <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br> </blockquote></div><br><br clear="all"><br>-- <br>Chris Messina<br>Open Web Advocate<br><br>Personal: <a href="http://factoryjoe.com">http://factoryjoe.com</a><br>Follow me on Twitter: <a href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a><br> <br>Citizen Agency: <a href="http://citizenagency.com">http://citizenagency.com</a><br>Diso Project: <a href="http://diso-project.org">http://diso-project.org</a><br>OpenID Foundation: <a href="http://openid.net">http://openid.net</a><br> <br>This email is: [ ] shareable [X] ask first [ ] private<br> </div> _______________________________________________<br>specs mailing list<br><a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs<br></blockquote></div><br></body></html>