[DotGNU]Re: Virtual Identities: standards work

[Peter Minten]

Stephen Compall wrote:
> Peter Minten wrote:
> > a lot is unclear about the DotGNU Common Virtual Identity System (DCVIS or
> > simply VIS). And with the current amount of active auth coders that's not 
> > likely
> 
> (define GBFM (choose-your-favorite-from CVIS VIS CVI DCVIS DVIS DCVI 
> DGCVIS DGVIS DGCVI :))

What does GBFM mean?
 
> The important thing is to remember that GBFM is not just address@hidden

I completely agree here.

> > to change soon. The VIS needs however to be integrated into the DotGNU 
> > System. I
> > therefore propose the following:
> > 
> > * We should create a specification of the VIS.
> 
> Somebody finally said it! :)

Check the attached file for a start on the specification.
 
> > * These specifications should be used to implement a minimal feature 
> > reference
> > VIS server.
> 
> Perhaps a reference library, GPLd, would be better? After all, the 
> implementation still has to define the environment.

I still prefer a standalone app, GPLd, Ruby, with much care for readability.
After all the reference server's goal is to show how it can be done, not doing
it for all situations. Oh and by the way Ruby is largely environment
insensitive.

If the reference server turns out to be a success the code could be rewritten in
C in lib form. That way we'd have the best of 2 worlds: an easy to code testing
server and a stable fast lib.

> > The way I see things there are a number of things to be put into the VIS 
> > spec:
> > * How the VIS server communicates with a webservice
> 
> IMHO, this is more of a DotGNU webservice standard issue than a GBFM 
> issue. That is, there are different ways to interact with it, depending 
> on the larger system. As long as you have full data access, the access 
> method doesn't affect the GBFM itself.

IMHO the GFBM standard is part of the DotGNU webservices standard. So the access
method does matter.

> > * How a Virtual Identity must be structured (note that this only applies to 
> > the
> > VI send over the connection with the webservice, the VIS server's internal
> > structure of a VI is unspecified).
> 
> Same as above.

Dito.

> > * What fields of a VI are mandatory (a field like name should be in all 
> > VI's)
> 
> Maybe a better name for the 'name' field would be "label"; it's a free 
> selection anyway.

Depends, does name refer to the name of the user or to the name of the VI?

> BTW, I believe there are owner-of-the-data issues here as well. Perhaps 
> the OOTD methodology, whatever it may be, will play into GBFM. So 
> hopefully OOTD can be resolved soon.

I'd love to hear your suggestions for that :-).

Greetings,

Peter

DotGNU Auth Spec
DRAFT VERSION 1

------------------------------------------------

Data types
==========

A VI can have fields of the following types:

Int16
        16 bits integer

Int32
        32 bits integer

Int64   
        64 bits integer

Single
        single precision floating point number

Double
        double precision floating point number

String
        text string of unspecified length

Binary
        binary data of unspecified length

Array
        array of fields, numbering is implicit

Hash
        hash (structure) of fields

Note that at the top level the VI data is contained in a nameless hash.


Encryption
==========

VI data MUST always be send over the network in encrypted form. The same
method as in GPG are used for that. The minimum key size is 1024 bits.
The prefferred keysize is 2048 bits (can't be secure enough with personal data).

Masks
=====

The user can specify masks for specific apps or groups of apps. A mask tells
the VI server what data may be transmitted to the webservice. It also tells
the VI server what changes the webservice may apply on the VI without explicit
user permission and what changes the webservice may never apply on the VI,
if no rule is specified for a field the default behaviour is that the VI 
server asks explicit permission to the user for the change.

Webservice directory
====================

Due to trust problems it will be inevitable to have a Trusted Third Party in
the system. A webservice directory would be a good choice for the standard TTP.
This has the advantage that the webservice directory could also serve as a 
discovery system.