This project is read-only.
Please see System Design ... but simply: there are Find, and Get, and Add actions on a webservice. There's a web ui, and cmdlets -- each of which can do all three of these actions. You can use Find and Get without authentication, but if you want to Add, we want to know who you are. On the web page, you can add them anonymously (maybe we'll use a javascript test to make sure you're not spamming us). But there's also a cmdlet, which will need to authenticate somehow because it's too easy to spam the service with a cmdlet in PowerShell ;-)

Originally I wanted to use OpenID for authenticationbut there's no way to do that from a client application, so just forget about it. We can, therefore, have usernames and passwords, or use something like CardSpace ... or we could just require scripts being submitted via the cmdlet to be code-signed -- maybe even require them to be signed by a certificate we can verify?

x0n said:

no reason the two can't be mixed somewhat, if someone logs into the site with a cardspace ID, perhaps the site can do the signing for us, based on a list of approved cardspace identities, (or maybe we sign people's cards -joel).

We really should make it as easy as possible to supply scripts, there are thousands of sites that already make it easy as possible by not demanding any of this hoopla. Maybe if someone logs into the site using cardspace (which is just a single click on an icon it appears), you could place the date and name of the author at the top of the script and sign the script with a private cert (belonging to the server) - that would allow us to verify the scripts as originating from us, and provide the identity of the author ... leaving nothing for the author to do except set up cardspace and upload a script -- without any of the ugly signing part of it, since the site will do that, killing multiple birds with one giant blunderbuss. We could even provide a verify-script cmdlet that would take the body of the script, submit it to the repository via wcf and the site would verify the signature...

Joel Said:

CardSpace is certainly very easy (and support is integrated into WCF). It might even be easier to issue verified InfoCards than to issue code-signing certs, but it's certainly possible to just allow people to link an InfoCard with their login -- then they can use that on the webUI and in the cmdlet... That's perfect for login.

However, code-signing, is the simplest powershell-oriented solution, and encourages users to code-sign. We could use CardSpace and put an author id at the top and sign everything saying we guarantee that the owner of this email address is the author of the script ... but I think that's going the wrong direction in terms of devaluing code-signing. The point of code signing should be that I can say I trust scripts signed by this cert -- and if all you have to do is validate an email address to be able to get your script signed by our webservice, then I can't trust the cert, so there's no point in signing at all.

I get that it's annoying that code signing certs cost so much money when all they have to do is verify that I'm me (I'm annoyed too -- and I only have a code-signing cert for work). I still think that long term, code signing is a better solution as long as it's integrated with the shell already -- but I'd rather create a low-trust Certificate Authority and issue certs with just an email and/or OpenId verification ... than to degrade the code signing completely by signing on the web server.

Last edited Jan 24, 2008 at 5:36 AM by Jaykul, version 2


No comments yet.