[sldev] [AWG] OGP Authentication Draft 3

[Kajikawa Jeremy]

Well the way I personally see things at the moment is this...

OGP is the door, the AgentDomain is a Trust Provider
 and the UGAIM services of any "grid" require a trust provider.

the U G and M services would have to have 2 methods of authentication,
 "local" where a person is not associated with an AD outside the
particular grid.
 "AgentD" where a person is associated with an AgentDomain and
associated services

anytime someone walks from one AgentDomain to another they will need to
be given
 a "default ruthing" unless prior access was involved.

Now I have an idea how this would work but the premise of it requires
that the
 technology used backs up a real world social dynamic and so far I see
potential
 of the whole situation getting perverted into an unusable mexican
standoff situation.

Not to dissuade anyone but the whole us vs them psychology is definitely
a beast that
 needs to be carefully dealt with along with the proper "chain of
custody" requirements.

its going to be too dammed easy at the service level if someone opts to
"go bad" to
 make the whole situation as it is a LOT worse unless everything has
some kind of
 "failover" security arrangement backing agreements.

so Im suggesting that anyone making any services and writing code
consider
 how to include both "default-allow-with-blacklist" and
"default-deny-with-whitelist"
 into whatever your writing at the moment and see which approach makes
sense...
 then document *why* it makes sense please...

I dont want to see the whole foundations for this become easily mangled
if an
 earthquake style event happens to the infrastructure (maybe the
building falls...)

I dont expect anything to come of what Ive said here but Ive said it
anyway...
 since without asking a question and getting a clearer idea of whats
around me
 I may as well stay blind and ignorant and easy prey (not my idea of a
good time).

On Wed, 2009-01-14 at 17:34 -0600, Escort DeFarge wrote:
> Food for thought indeed.
> 
> I guess my take was that OAuth could equally well start the chain of 
> capability from an (at least partially standardized) http login. I 
> hadn't really expected it to generalize out to object-level perms ...and 
> it was my understanding that even Open ID relies on a TTP.
> 
> Thanks for the reply.
> 
> /esc
> 
> 
> Meadhbh Hamrick (Infinity) wrote:
> > but seriously. OAuth is a step in the right direction, but...
> >
> > a. it depends on HTTP. we think linking application level objects 
> > (like application object access control metadata) with a specific 
> > transport is a bad idea.
> > b. as far as i can tell, it doesn't have a resource for managing 
> > distributed access-control tokens. there seems to be an assumption 
> > that all access control will be managed by the same administrative 
> > party. that being said... there appears to be nothing in the spec to 
> > PREVENT you from adding this feature, and I've pinged the OAuth peeps 
> > from time to time about it, so who knows.
> > c. OAuth is for securely transporting object access control metadata, 
> > OGP Authentication is for authenticating an end user to a service 
> > cloud. OGP Auth is actually a little closer to OpenID than to OAuth. 
> > But i think you're asking... why not return an OAuth compliant PDU as 
> > a result of successful OGP Authentication. hmm... no reason it can't 
> > be done from a protocol perspective, but we would have to get with the 
> > OAuth people and get them to fix problems a and b above before we 
> > would likely deploy something like that.
> >
> > -cheers
> > -meadhbh
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090115/5bf324fc/attachment.pgp