Re: [Auth]ISsec Profile Providers (was Re: IDsec meeting)

[David Sugar]

At the most basic level, in IDset, you have a profile provider which has 
a list of attributes which can presumably be expanded as needed, values 
associated with those attributes, and access control for how each 
attribute is shared that the user controls.  From that, a content 
provider uses a session certificate that the user provided to request 
that user's profile from the profile provider, and the profile provider 
can then return a generated XML spec document with those attributes that 
the given content provider was permitted to see by the user.  This can 
be carried on http and ssl for secure connections.

This is a simplified representation of how it works, but I think it 
essentially answers your question.  To make IDsec work the way you 
suggest may simply requires the user to be able to define their own 
attributes.  Also, there is discussion of the possibility of having the 
content provider also store data for the user at the profile provider (a 
bit like a cookie...) although I do not believe this is directly part of 
the IDsec spec yet.


Mike Warren wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "John Pugh" <address@hidden> writes:
>
> > My point above was that there will be a base identity schema as you
> > depicted via XML. But as a provider, I want to provide other
> > services or add another layer of "service" to make my providing or
> > service more appealing.
>
> Ah, I see. Absolutely.
>
> > First...in the IDSec space...can this be done?
>
> I don't know; all I know about IDsec is what's been written here on
> address@hidden; I would certainly advocate that such extensibility
> should exist.
>
> > With XML, it's simple to do that and the interface can be
> > automatically modified to support the additional attribute AND the
> > attribute/schema can easily be limited to just that provider.
>
> Yes, I think expandability is important; my example about a Bank
> perhaps wanting to add the ability to issue digital cash tokens would
> use this. If a User has a digital cash token, they will almost
> certainly want to send it so some Third Party. Since any feasible
> digital-cash scheme must include recipient information, it makes sense
> to send it along as some ``extra'' information between two Identity
> Clients.
>
> > I'm struggling with the need to re-invent the wheel here...or maybe
> > that's what you want to do? I'm not sure.
>
> I'm not aware of a robust, open, trust-based Identity model such as
> the one I discussed in my last mail which is implemented as free
> software. The ``Nym'' system (now disabled) implemented by
> ZeroKnowledge.com comes close-ish, but it depends on central servers
> and doesn't allow one to issue themselves a Nym (Identity). It also
> doesn't allow (for example) a company to issue Nyms to its employees
> (well, they could set up their *own* system, but that defeats the
> purpose). They may very well have some usable code, though.
>
> > Thanks for reading...I'll stop if I'm impeding progress. Just say
> > so.  This IS good stuff.
>
> No; all comments are valuable, IMO. Readers can ignore those authors
> they don't find valuable.
>
> - -- 
> address@hidden
> <URL:http://www.mike-warren.com>
> GPG: 0x579911BD :: 87F2 4D98 BDB0 0E90 EE2A  0CF9 1087 0884 5799 11BD
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.1 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard 
> <http://www.gnupg.org/>
>
> iD8DBQE8CDKLEIcIhFeZEb0RAjXIAJ9KW2gFkFmz4rYGNdKHL/sXnlTzJQCfR4vc
> LEfcbkF4OLaZ9l5ZnTavwB4=
> =Eka5
> -----END PGP SIGNATURE-----
> _______________________________________________
> Auth mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/auth