Out of curiosity, beyond the email discussion below what are the
primary metadata needs around the other major (PoCo) fields?
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).
Jonathan
On Dec 8, 2009, at 2:17 PM, Chris Messina wrote:
Is it worth looking at how Facebook handles the passing of profile
data? Or is their architecture/use case different?
http://wiki.developers.facebook.com/index.php/Users.getInfo
On Tue, Dec 8, 2009 at 11: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
--
Chris Messina
Open Web Advocate
Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina
Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net
This email is: [ ] shareable [X] ask first [ ] private
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
