<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: magnolia</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/magnolia.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2007-06-30T21:28:30+00:00</updated><author><name>Simon Willison</name></author><entry><title>A note about simple registration</title><link href="https://simonwillison.net/2007/Jun/30/sreg/#atom-tag" rel="alternate"/><published>2007-06-30T21:28:30+00:00</published><updated>2007-06-30T21:28:30+00:00</updated><id>https://simonwillison.net/2007/Jun/30/sreg/#atom-tag</id><summary type="html">
    &lt;p&gt;&lt;a href="http://openid.net/specs/openid-simple-registration-extension-1_0.html"&gt;Simple registration&lt;/a&gt; is an extension that allows OpenID consumers to ask your provider for extra information - your name, e-mail address, date of birth and so on.&lt;/p&gt;

&lt;p&gt;Unfortunately, the spec often causes confusion for implementers. Here's the tricky part:&lt;/p&gt;

&lt;blockquote cite="http://openid.net/specs/openid-simple-registration-extension-1_0.html"&gt;
&lt;dl&gt;
&lt;dt&gt;openid.sreg.required:&lt;/dt&gt;
&lt;dd&gt;Comma-separated list of
	  field names which, if absent from the response, will
	  prevent the Consumer from completing the
	  registration without End User interaction.
&lt;/dd&gt;
&lt;dt&gt;openid.sreg.optional:&lt;/dt&gt;
&lt;dd&gt;Comma-separated list of
	  field names Fields that will be used by the Consumer, but
	  whose absence will not prevent the registration from
	  completing.
&lt;/dd&gt;
&lt;/dl&gt;
&lt;/blockquote&gt;

&lt;p&gt;This is often interpreted as meaning that you can pass along a list of required fields and be guaranteed that they will be handed back to you. This is not the case: some providers (&lt;a href="http://idproxy.net/"&gt;idproxy.net&lt;/a&gt; for example) don't support simple registration at all; others (like &lt;a href="http://wordpres.com/"&gt;WordPress.com&lt;/a&gt;) only support a subset of the fields, since they don't store details such as the user's postcode. If your provider insists on certain values being returned by simple registration, some of your potential users will be unable to sign in.&lt;/p&gt;

&lt;p&gt;The misunderstanding stems from the definition attached to the required field. When you make a simple registration request, you're providing &lt;em&gt;advice&lt;/em&gt; to the provider. You're essentially saying that the user is going to have to provide this data eventually in order to register with your service, so it would be really handy if the provider could send it over to you. If they don't, your application will have no choice but to ask the user for it directly.&lt;/p&gt;

&lt;p&gt;In other words, even if you specify required values you shouldn't expect them to come back every time.&lt;/p&gt;

&lt;p&gt;By far the best way to use simple registration is as a way of pre-filling a signup form for your user. Many applications ask the user to complete a short registration form the first time they sign in with their OpenID. Use simple registration to pre-fill some of those form values - that way, if it's not available (or some of the values are missing) your application logic doesn't really care, it's just one more form field that the user will have to complete themselves. &lt;a href="http://ma.gnolia.com/"&gt;Ma.gnolia.com&lt;/a&gt; is a great example of a site that does the right thing.&lt;/p&gt;

&lt;p&gt;See also &lt;a href="http://openid.net/pipermail/general/2007-March/thread.html#1874"&gt;this thread on the mailing list&lt;/a&gt; from back in March.&lt;/p&gt;
    
        &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/idproxy"&gt;idproxy&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/magnolia"&gt;magnolia&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/openid"&gt;openid&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/sreg"&gt;sreg&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/wordpress"&gt;wordpress&lt;/a&gt;&lt;/p&gt;
    

</summary><category term="idproxy"/><category term="magnolia"/><category term="openid"/><category term="sreg"/><category term="wordpress"/></entry><entry><title>Ma.gnolia Blog: OpenID is Taking Off!</title><link href="https://simonwillison.net/2007/Jan/22/magnolia/#atom-tag" rel="alternate"/><published>2007-01-22T18:41:17+00:00</published><updated>2007-01-22T18:41:17+00:00</updated><id>https://simonwillison.net/2007/Jan/22/magnolia/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://ma.gnolia.com/blog/2007/01/22/openid-is-taking-off"&gt;Ma.gnolia Blog: OpenID is Taking Off!&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Since November, 15% of new Ma.gnolia members signed up using an OpenID.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/magnolia"&gt;magnolia&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/openid"&gt;openid&lt;/a&gt;&lt;/p&gt;



</summary><category term="magnolia"/><category term="openid"/></entry><entry><title>Ma.gnolia supports OpenID</title><link href="https://simonwillison.net/2006/Dec/17/magnolia/#atom-tag" rel="alternate"/><published>2006-12-17T09:29:05+00:00</published><updated>2006-12-17T09:29:05+00:00</updated><id>https://simonwillison.net/2006/Dec/17/magnolia/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://ma.gnolia.com/blog/2006/11/30/sign-in-your-way"&gt;Ma.gnolia supports OpenID&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Text book implementation: you can associate your OpenID with an existing account and log in using either OpenID or your regular username and passwerd.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/magnolia"&gt;magnolia&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/openid"&gt;openid&lt;/a&gt;&lt;/p&gt;



</summary><category term="magnolia"/><category term="openid"/></entry></feed>