dotgnu-auth
[Top][All Lists]
Advanced

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

Re: [Auth]Okay, so how about some code...


From: John
Subject: Re: [Auth]Okay, so how about some code...
Date: Fri, 05 Oct 2001 00:51:48 -0500

Thoughts:

Mason Ham wrote:
> 1) Bob goes to foo and asks for a protected page.
> 2) foo checks if bob is already auth'd with it. Bob isn't so it make an
> auth. packet and "transmits" it to the client. At this point the client
> could view the encrypted data going from foo to bar. Not much use in that
> though....
> 3) bar gets the request, checks if bob is already auth'd with it. Bob isn't
> so it sends a login screen to bob. bob fills it out and sends to bar.
> 4) bar process and does what need to be done with LCRS. In this case bob has
> stated that he wants to approve data going to this site. So bar send him a
> form for approval. He says yes.
> 5) bar encrypts the information with foo's public key. and "transmits" the
> data to bob to be redirected.
> 6) This is where the 3.2 dependence comes in. In order to make it happen one
> must use the onload even from the scripting subsystem. the other option is
> to have form post to a button for bob to click to send it.
> Hope that is clearer.

Replace the "encrypted packets" with "symetrically encrypted cookies"
and you've described Passport's mechanism. So, where's the difference?

This still does not prevent the data or metadata from being mined by B,
which was another requirement of the DotGNU design. Wasn't it?
John Le'Brecage


reply via email to

[Prev in Thread] Current Thread [Next in Thread]