<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">(I thought I posted a reply but since it does not appear in the archive etc...)<div><br></div><div>+1 to Breno's point. </div>
<div><br></div><div>With Artifact Binding, you will not have to worry about the URL length limit, </div><div>and we get the benefit for other extensions as well. </div><div><br></div><div>We have working code for Artifact Binding for Python, Java, and now making PHP </div>
<div>version. </div><div><br></div><div>For making a custom grouping of the attribute, we can create a file that contains the list and use the file's URL as the group's type URL. Current draft of Contract Exchange has such facility. It stores the ax request in one of the node of the Contract Document (which has other items like signature etc. as well.) </div>
<div><br></div><div>=nat</div></span><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 4: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><div class="im">> _______________________________________________<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>
</div><font color="#888888">--<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>
</font><div><div></div><div class="h5">_______________________________________________<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>
</div></div></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>