Thank you (et al) for getting this draft up! I love the frenzy of publishing right before IIWs.
I totally appreciate the argument for a minimal JSON userinfo. I'm in favor of whatever gets adoption, and with JSON parsers everywhere, it's definitely easy to implement. Not that I grok why sreg didn't get adopted better, it's half the pragmatic appeal of OpenID to me. But my hunch is that people didn't adopt sreg because sreg code only got you sreg. If I could get that data using hcard, who knows, I might use that code for other features in the future. If I could get it in poco, maybe I can reuse that code to import contacts in the future. But you aren't going to reuse sreg code for more features in the future. And AX seems to have a chicken and egg problem. Not enough AX data now, so no push to implement, so no demand for more data. I'd really like the user info api to give the impression that implementing doesn't just buy you a one-off feature, but gets you infrastructure you'll reuse in the future. That's partly why I'm worried about api extensions in the future. XML namespaces are nasty, but they let you say, "this element can contain stuff defined elsewhere. Ignore it if you don't understand what's there. Go nuts." Until we get a standard way to do that in JSON, people are going to be afraid of extending it without someone's blessing. Or someone will extend it, and some blogger will misunderstand and scream "Google is Abandoning Standards and Forking OpenID" across hn and reddit. Not that that's ever happened. Maybe I'm worrying too much and people will suggest reasonable extensions and they'll be widely adopted on merit. No troll threads or anything. Sounds delightful. As for using host-meta/XRD/JRD (perhaps we should call it a *RD?) as an endpoint with OAuth, I hope we'll make some progress on that in an XRD provisioning session this week. There's a decent strawman spec out there I keep meaning to implement. Seems like these ideas can play nice with each other. On May 16, 2010, at 1:33 AM, David Recordon wrote: > Oh, and in terms of using host-meta / JRD for profile info. I think we're > going to get there. If I pass an OAuth token into a JRD endpoint I might see > service endpoints that the user didn't expose publicly. I also sort of like > the idea of making the user identifier an API endpoint itself. > > > On Sat, May 15, 2010 at 11:31 PM, David Recordon <[email protected]> wrote: > Thanks Joseph! > > When proposing the User Info API (http://openidconnect.com/#API) I was really > looking to establish what the minimum requirements are to provide the value > that sites are asking for and be interoperable. It's pretty clear that JSON > is the correct format for this API versus XML or returning HTML snippets. > Both Simple Registration and Attribute Exchange are schemas which rely on > OpenID 1.0/2.0 messages for syntax and neither have been widely adopted. > > From there I started looking for profile APIs in JSON. Portable Contacts is > the leading technology, but is too isn't widely adopted today. OpenID, OAuth, > Twitter, and Facebook all use underscores in parameter names while Portable > Contacts uses camelCase. I thus decided to take the parameter names in > Portable Contacts – Joseph Smarr did a lot of research into good > internationalized names – and convert them from camel case. I also flattened > the lists since the API is meant to be minimal and simple, but extensible by > servers. > > Thus displayName became display_name and name:firstName became first_name. > > As I said on the site, I fully expect Portable Contacts, Activity Streams, > etc to be deployed with OpenID Connect and even have those sorts of APIs be > used more actively than the simple User Info API. By providing what's > required for interop and an OAuth token we're able to push innovation around > APIs out to other communities versus trying to make OpenID do everything > itself. > > So all of that said, any suggestions of how the User Info API could do a > better job of reusing existing schemas? > > Thanks, > --David > > > On Sat, May 15, 2010 at 11:12 PM, Joseph Holsten <[email protected]> > wrote: > David Recordon wrote: > > Basically moving us to where there's a true technology stack of TCP/IP -> > > HTTP -> SSL -> OAuth 2.0 -> OpenID -> (all sorts of awesome APIs). Not just > > modernizing the technology, but also focusing on solving a few of the key > > "product" issues we hear time and time again. > > I started a response, but it got into tldr territory, so I blahged instead. > Briefly, let's not reinvent the user info wheel another time. > http://blog.josephholsten.com/2010/05/your-new-new-web-identity/ > -- > http://josephholsten.com > _______________________________________________ > 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
