(I thought I posted a reply but since it does not appear in the archive etc...)
+1 to Breno's point. With Artifact Binding, you will not have to worry about the URL length limit, and we get the benefit for other extensions as well. We have working code for Artifact Binding for Python, Java, and now making PHP version. 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.) =nat On Wed, Dec 9, 2009 at 4:08 AM, Breno de Medeiros <[email protected]> wrote: > On Tue, Dec 8, 2009 at 11:01 AM, John Panzer <[email protected]> wrote: > > For "one-time" URLs, you'd probably want to allow for retries for a short > > period (or just allow it to be accessed for say 5m) which would have > > approximately the same level of protection. > > You could also imagine long-lived capabilities along the lines of OAuth > > tokens that allow RPs to repeatedly refresh the data as needed. (Better > of > > course if they can subscribe to changes, but that's an implementation > detail > > and definitely a separate spec.) > > Given that AX already supports requesting URL-valued data (e.g., profile > > photos) I think this just comes down to defining a fairly complicated > data > > type for AX and passing a URL around. > > A more lightweight alternative is to adopt an 'artifact' mode where > most of the OpenID assertion (request and response) can be passed in > the backchannel. That is a bit more difficult to implement but easier > to spec (because the existing URLs can be used) and more general > (compacts all extensions, not only AX). > > > -- > > John Panzer / Google > > [email protected] / abstractioneer.org / @jpanzer > > > > > > > > On Tue, Dec 8, 2009 at 10:57 AM, Peter Watkins <[email protected]> wrote: > >> > >> On Tue, Dec 08, 2009 at 10:32:12AM -0800, John Panzer wrote: > >> > >> > provide to RPs. If you send an endpoint URL to the RP instead of the > >> > information itself, the RP can then retrieve it via a backchannel (and > >> > cache > >> > it). If you have private data, use a capability URL with a token that > >> > allows read-only access. > >> > >> Exactly. OpenID requests and responses are very chatty, and backchannel > >> URLs could be an easy way to get around the 2k GET limit (the cost of > >> course being additional time needed to make the additional HTTP > requests). > >> > >> I don't see any reason for backchannel URLs to be requested multiple > >> times, > >> so in addition to a request or response using strongly random nonces in > >> the backchannel URLs, the backchannel URLs should be very short-lived, > >> probably each side "SHOULD" allow a URL to be requested only once, and > >> throw a 403/404 for subsequent requests. > >> > >> Is there any draft of AX using backchannel URLs? > >> > >> -Peter > > > > > > _______________________________________________ > > specs mailing list > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-specs > > > > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- Nat Sakimura (=nat) http://www.sakimura.org/en/
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
