Re: [Auth]Re: [DotGNU]A Proposal for a Solution (please read the end at least)

[Myrddian]

I thought of this scenario, one way to have AuthCO and not some buddy on a 
linux box
would be to have a Secondary Auth System, well this secondary system verifies 
the actual
Auth Server it self not the client. That way the ticket company can "trust" 
this 
AuthC0 server.

The other thing I saw was XNS, now XNS tries to solve this issue by using 
tighter 
control on how these Auth server certificaes are handed out.

So there could be two ways.

1) Have a Auth System in which a Secondary Auth server verifies the "unknown"
   auth  server. In this case the Secondary Auth would have to explicitly
   know of the existance of this AuthServer. I'll have to think about this more

2) Use XNS, as a secondary fall back, from primary doco's I've seen its very
   interesting. However there are issues with it, and it might be dead.
   It's status is unknown and I dont know if XNS support could be implemented
   I Think David is taking care of this one, but he's gone overseas 




> > And for Authentication and Identity for the Jabber system, this is being
> > taken care of, as well. By none other than myself and a small group of
> > others who are making fast progress on an open, flexible, powerful, and
> > very secure Identity system that runs using Jabber. For more information
> > on this, head over to http://www.theoretic.com/identity .
> 
> Your current status looks good. I do like the ticket idea because its
> simple, but all seem to have a problem I havent figured out myself. Let
> me try and explain a problem I see:
> 1) Joe wants to use service of CompanyA
> 2) Joe has an authentication account with AuthCo and so he logs in and
> gets a ticket
> 3) Joe shows his ticket to CompanyA who verifies with Authco
> all is well.
> But... how does CompanyA know that AuthCo is a trusted source and that
> Joe didnt just set himself up an auth server on a linux box in the
> corner?
> 
> If we have a distributed system like this, there might be need for a
> master registar of 'trusted servers'. Then it would work like this:
> 1) Joe wants to use service of CompanyA
> 2) Joe has an authentication account with AuthCo and so he logs in and
> gets a ticket
> 3) Joe shows his ticket to CompanyA
> 4) CompanyA sees that the ticket is from AuthCo and checks the registar
> for AuthCo's listing. If AuthCo is listed then it moves on, otherwise it
> can deny or accept depending on some settings that CompanyA's admin
> sets.
> 5) If we get this far then CompanyA verifies Joes ticket and the
> transaction can proceed


Well Like I said in (1) You could contact a "Trusted" Auth server, this server
then can verify the Auth server in which the user is using. You could to 
peer-peer
routes but once again this leads to some interesting issues. Secondly who is 
this master
registar? Another company? 

(2) XNS, Has something which deals with this, but I dont know what the 
situation with it is.



Well Jabber as far as I see it is a good way for the Virtual Identities system 
to work.
However, the scope of DotGNU is far more larger and is a tad bit more scaled 
that Jabber
was intended for ( I feel any how ). So extensions as such and a better 
mechanism
might be needed. I'll have to read more on it any how, but it's quite good so 
far :) 

__________________________________________
Myrddian <address@hidden(nospam)au>
-------------------------------------------
"I stayed up all night playing poker with tarot cards. I got a full house
 and four people died". 

                   -- Steven Wright