[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]

- Something that creates a request (websites, etc)

- A client which handles the request and tries to get the information (e.g. 
browser plugin) and the user can choose which information will be sent back. 
The client use the interface of the dotGNU framework to retrieve the 

- The Framework looks at the requested information and request the underlying 
services for the information. The framework doesn't know, which service 
provides the information but can ask the services which are registered 
through a service provider

- The service providers make a connection to the services

- The services sent the requested information back to the service provider, 

The implementation of the auth service may use the technique below:
A few people already made suggest how to handle authorisation/authentication. 
But they all mentioned some kind of a central repository. I think it would be 
nice if auth can be handled through a "web of trust" like in PGP, which we 
could use. This approach has serveral advantages:

- Anybody can create one or more identities
- If the identity should be accepted by a online shop he can go to a trust 
center and let them sign his identity (e.g PGP key) after proofing his 
- PGP (OpenPGP) is also widely used at the moment and is an accepted standard

Other opinions?


From that each .gnu auth server goes to a user/password page. And then
if the user authenticates acts as a https proxy between the site and the =

It's ugly. But it will work with _any_ browser that can handle forms. uses
existing technology and doesn't involve any plugins.

And as far as actual authentication goes it's all up to each individual =
.gnu auth server.=20


>>> Nick Lothian <address@hidden> 07/16/01 11:19am >>>

> On Mon, Jul 16, 2001 at 09:45:36AM +0930, Nick Lothian wrote:
> > I don't think an architecture relying on browser plugins or=20
> any special
> > client side software is going to work.
> And any architecture that doesn't require trusted client-side software
> makes it impossible to implement a scheme that doesn't entirely trust
> J. Random Website with your secret key, but instead permits a trusted
> third party to mutually authenticate client and server, a la Kerberos.

Not unless the authentication is actually done on the passport/Auth.GNU
site, and then the browser sent back to the site that requires


Auth mailing list

From a brief look at their homepage, it doesn't seem to be Free
in the sense of Free Software.

But since Hailstorm is a threat to their business, too, maybe
they can be talked into supporting the DotGNU project by
realeasing some valuable chunks of code under GNU GPL.

I'd suggest that Ron Burke would be the right person to try
talking with them.  I think that Ron is the one who currently
has the best grasp of what we need.

Greetings, Norbert.

Norbert Bollow, Weidlistr.18, CH-8624 Gruet  (near Zurich, Switzerland)
Your own domain with all your Mailman lists: $15/month
Business Coaching for Internet Entrepreneurs --->
Tel +41 1 972 20 59      Fax +41 1 972 20 69      address@hidden

From a practical point od view, the enduser should simply pick
the same username for both servers. Then he only has to remember
two passwords and two locations. He could even use the same
password but then hacking into the system would be made much

Two minor comments follow:
a) HTTP GET is not supposed to be used for this kind of data
   modification.  Use HTTP POST instead.
b) This is not reliable enough.  In case of network problems
   with the connection to server2, the two servers can easily
   get out of sync.  I'm sure you'll be able to come up with a
   solution to this problem though.

Point a: You're right, but for the purpose of this discussion I 
wanted to keep everything as simple as possible. 
Point b: That's why I used versions. They guarantee that a 
valid version exists as long as you don't make more than one
change between server backups. The other problem, a complete
server failure, will be dealt with later today.

Carsten Kuckuk

From what I can tell, there is no clear statement for
what DotGNU Platform or Virtual Identities is trying
to solve. We know that "DotGNU will be a complete
replacement for the .NET strategy" and I think this is
very necessary. I also tink that there should be a
statement outlining DotGNU's purpose, or the problems
DotGNU is trying to solve. To get a thrust of what
DotGNU will be about, I had to go to microsoft's
whitepaper site
The only reason I bring this up is that I think it is
dangerous to always follow something out of protest.
I've found it's better to reach for a goal because it
solves some major technical hurdle or information
need. What do people think? Has this been discussed?


Do You Yahoo!?
Get your free address at

From the quick look that I have taken at IDSec I would agree
that it is broader in scope.  Specifically, it appears to me
to include specification for a single authentication scheme
which content providers would be required to adopt. Whereas,
it is the aim of Flysolo to provide a facility for
integration with various existing authentication schemes.
The aim being rapid adoption by existing content providers.

> If only the documentation for Flysolo were available, some of its ideas
> might be useful. As it is, you'd have to look through the header files
> (at to piece together the profile query
> and storage APIs.

I apologize for the disappearance of the Flysolo
documentation. My ISP is in the process of changing things
around related to the address@hidden financial troubles. The
location of my personal webspace has been affected and I
have yet to set it up at the new location. Also, the
documentation is a bit out of date with some of the current
ideas that I am developing. I will let you know when I have
updated it, and where it is.

> (For the record, and since clear information about Flysolo is hard to
> come by these days, Flysolo is more general than single-login -- it
> extends that idea to arbitrary information, silently requested by a
> website through an <embed>'ed query and responded to according to a
> user's configuration. The mechanisms are tuned a little towards
> automagically filling in html forms. Flysolo provides two libraries: one
> for processing these embedded queries and one for processing a stored
> user profile. Implementation details, such as filling in a form, are left
> out.)

Yes, specifically, the Simple Interface Markup
Language(SIML) spec is a very general facility for
specifying interface repository instances for arbitrary web
interfaces. The Flysolo project uses SIML to integrate with
existing web based authentication schemes. However, the uses
for SIML are limited only by your imagination. :)


From the spec:
> "When starting a web session that requires the use of IDsec, the user will 
> login
> with the Profile Provider with a username/password combination. This "session 
> login"
> will result in the creation of a so-called session certificate that is sent 
> to the user.
> The session certificate merely consists of a session identifier and a URL that
> indicates the location of the user's profile.
> The users web-client sends the session certificate to the IDsec enabled 
> web-site
> of the Content Provider. The Content Provider in his turn, sends it together 
> with
> his own certificate to the URL specified in the session certificate over a 
> secure
> connection.

<rant class="reasoned">

In this information exchange architecture, the Content Provider "needs"
to know the URI of the agency where I store my data to conduct a
transaction? That meta-data (who my content provider is) is my private
business! Unless I want to tell the content provider where my data is, I
should not have to, but the IDsec transaction architecture forces me
too! Additionally, the Profile Provider knows who I am interacting with
by virtue of the IP address of the requestor. My profile provider should
not know whether I'm accessing the Wall Street Journal anymore than he
should know I'm accessing a pay-per-view porn camsite. That information
is my private business regardless of who I am, or what I am accessing.

Once my Content Provider knows who my Profile Provider is, they can
collude to gain additional information. Since I'm out of the loop, I'm
left to wonder "how did that information get out?" "Why am I suddenly
getting spam from Barron's and Fortune? I read the Wall Street Journal?"
Simple: my Profile Provider knows my e-mail address, and he knows that I
read the WSJ. He can then shop the other info to Barron's and Fortune.
What's to stop him? Apiece of paper that he can change at will?

IDsec *requires* that I trust my profile provider, now and in the future
and for all time. I shouldn't have to. IDsec requires me to. IDsec may
let me distribute only the personal data I choose, but (and this is a
sticky but) IDsec gives me no control over what metadata I distribute.


Hans, I'm still working on the schema extraction of the Mozilla wallet.
Still interested?

John Le'Brecage

Hans Zandbelt wrote:
> Doesn't anyone have any comments on the draft spec that I
> sent 2 weeks ago? (or should I stop bothering...)
> Hans.
> ------------------------------------------------------------
> Hans Zandbelt                         address@hidden
> Telematica Instituut           
> P.O.Box 589, 7500 AN                   Phone: +31 53 4850445
> Enschede, Netherlands                    Fax: +31 53 4850400
> _______________________________________________
> Auth mailing list
> address@hidden

From the above one can easily infer that transactional, "who deals with
whom", meta-data is in and of itself is minable! I've said it before,
and I'll say it again: ID-Sec breaks the very requirements that were
established way back when - no mining; not even of metadata. The council
had good reasons for that requirement.

Your solution vis-a-vis IDSec has always been: If the Owner wishes to
prevent incidental meta-data mining, then the Owner should be their own
service provider and run ID-Sec locally. The meta-data won't be mined
because the Owner has assumed the role of the entity that can collect in

Think though: How does self-hosting fit into the required remote usage
scenario? That's the question that was left unanswered last time round
the tobaggan trail. To recapitulate: One of the reasons people use a
service provider is for the up-time and access warrantee. Suppose you're
on vacation and flip open your PocketPC only to discover that a power
glitch has occurred at "home", and there's no-one there to reboot your
machine? What if your ISP disconnects at "home" and on reconnect your
self-providing Manager is relocated to a different IP, and thus you
can't find "yourself" from the P-PC? There you are: unable to access
your profile data, in what could be an emergency scenario?

I think we all can agree: these are two very sane reasons to have a
third-party Manager provider, and as explained ID-Sec opens the door to
mining at the Manager by it's very design. Making the third-party
"option" ever so much more attractive than first party scenario, leaves
the barn door wide open and swats the horses on their collective rumps.

In our previous rounds of discussion we were dealing with an imbriglio
of design: I voiced my objections and allowed myself to be shouted down
because it's your project. Now, the question becomes one of expedient
decision based on other than mere technicality - the design is unchanged
and nears implementation and may soon affect other projects. The
decision is rapidly upon the body politic: Does DotGNU expediently adopt
the ID-Sec product with the knowledge that it can be used as described
or do we stick by the original design edicts dictated by our moral
imperatives?  Show me that such transitivity cannot occur and I will
renounce my objection, but until then I will continue to write as I have
written and object as I have objected.

That's my duty as a thinking member of a democatic body, which
supposedly both Dot-GNU and FreeDevelopers are.

John Le'Brecage

Hans Zandbelt wrote:
> At 02:54 3/15/2002 -0600, John wrote:
> >That's it. Although ID-Sec has been much better supported, I still see
> >it's failure to protect the "sites-visited meta-data"  as a major
> >departure from DotGNU's original edict of fully protecting customer
> This is *not* an IDsec problem!
> IDsec in itself *does* guarantee that Profile Requesters cannot relate
> eachothers data by using "meaningless" session identifiers!
> However it depends on the nature and the amount of the
> data itself that you give to Profile Requesters wether this will actually
> work out: if you pass your private address to Profile Requester A and to 
> Profile
> Requester B, it's quite logical that they will be able to associate
> these visits with the same person ... This is not an IDsec problem:
> it's a problem that you would have with these Profile Requesters.
> You shouldn't give this kind of profile data to malicious Profile Requesters;
> The only thing IDsec can do is that it won't give this kind of data to
> Profile Requesters that you don't trust.
> As a matter of fact, Service Providers today can easily assemble user
> profiles bases on client IP addresses. This is also an issue that will
> not be solved and that is out of scope here.
> I have explained this before and you can read it in the draft
> specification. Please do so before making this kind of statements!
> Regards,
> Hans.
> ------------------------------------------------------------
> Hans Zandbelt                         address@hidden
> Telematica Instituut           
> P.O.Box 589, 7500 AN                   Phone: +31 53 4850445
> Enschede, Netherlands                    Fax: +31 53 4850400

reply via email to

From: Unknown
[Prev in Thread] Current Thread [Next in Thread]