I would think we'd only need an additional type if we couldn't identify the cards through names, no? 

Perhaps it would make this clearer if we got a bit more concrete.  let's say we want a twitter account.  What information do we want to store?  A handle and a password?

perhaps that could be done with a +*twitter card that includes either +*handle or "_left+*twitter handle".  If so, we can deal with all of that without a new type, no?

I was thinking that custom login attributes are accessed from a common +*account card, so then +*account would need to have another dimension to select which provider. My question is why not a type? we are using the tag to say it is an authorizable entity, but we could have +*twitter_account and +*oauth_account. I don't have a strong preference, but I think one attribute name is cleaner.

Maybe the representation is a pointer card that has one or more possible cards that have an auth-provider behind them and we could just use any patterns to get the custom functions of a specific provider.

  --Gerry Gleason.....2012-11-15 20:00:04 +0000

Let's say I package our User class as a provider, call that WagnAccount and connect it to the RightAccount sets. Now I add a twitter provider, how do I say that the Gerry user can log in locally (User model) or use twitter?

  --Gerry Gleason.....2012-11-15 20:04:10 +0000

I could imagine storing in the account (+*account) card content a whole authorization configuration for the user. Maybe use Json (sort of like Search cards and wql, the underlying rep is just different. Has some real potential combined with obj_render branch integration.

  --Gerry Gleason.....2012-11-15 20:07:40 +0000

I think it would be helpful for me to play with sample data (maybe in the example card?). Let's say we have a user named Horace who has a standard wagn login info and is also set up to log in with twitter or facebook. What all information might we want to store about him?

If we get some play data, the we can move back and forth between representation and implementation ideas.

  --Ethan McCutchen.....2012-12-06 21:14:25 +0000

Sounds good. I'll use the example of twitter (and maybe openId if I can do two, FB if three). I think abstractly, there is a primary key to identify the login, email for Wagn logins and many others, twitter @id is a simple user name, the only issue is name validation in most cases. That key can have a characteristic name, but maybe we use something like :account_identity. The value and validations would be up to the auth provider, but it should include any standard syntax markers (i.e. the @ is @ddenizen and the @'s and .s in email gerry@geraldgleason.com, or http://myopenid.geraldgleason.com/gerry for open id ...)

  --Gerry Gleason.....2012-12-10 19:26:04 +0000

Gerry+*account+*twitter -> (content) @ddenizen

Gerry+*account+*email -> gerry@geraldgleason.com

Gerry+*account+*openId -> http://gerry.openid.geraldgleason.com/

  --Gerry Gleason.....2012-12-10 19:33:51 +0000

OmniAuth twitter strategy I wonder how hard this will be now ...

  --Gerry Gleason.....2012-12-10 19:39:25 +0000

I think that as with email, we will be able to reference these as: Gerry+*twitter ... as well, but it will be bound to the +*account cards to be able to use it with a session.

  --Gerry Gleason.....2012-12-10 19:41:45 +0000

I only took a brief look at OmniAuth and OmniAuth twitter. My guess is that we'll often be good with rack extensions (like OmniAuth) more or less unaltered. Rails gems will be a little more hit or miss; we'll especially have to avoid those that add data structure. But I don't see that with a brief glance.

It does look like both expect data to be in place at run time, so we may have degree of complication around card-based configuration. Wondering if one of the common "events" isn't going to be re-load...

  --Ethan McCutchen.....2012-12-10 22:12:48 +0000