Organized README, CHANGELOG and notes/;

renamed notes/* (removed README- prefix)

notes/AccessControl.txt

@@ -0,0 +1,2 @@
+
+See the notes in [[Authorization]]

notes/Authentication.txt

@@ -0,0 +1,5 @@
+Guides to best practices:
+* "The OWASP Guide to Building Secure Web Applications":http://www.owasp.org/index.php/Category:OWASP_Guide_Project
+** specifically, of course, the chapter on Authentication.
+* "Secure Programming for Linux and Unix HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
+* "Authentication and Identification,":http://www.downes.ca/post/12 by Stephen Downes **Highly Recommended**

notes/README-Authorization.txt → notes/Authorization.txt

@@ -17,6 +17,7 @@ h2. Authorization
 
 h2. Authorization in a trust context
 
+* [http://en.wikipedia.org/wiki/Authorization]
 * remember: goal is **prediction** not **control**
 
 h2. Patterns for Policy definition / Authorization / access control

notes/README-RailsPlugins.txt → notes/RailsPlugins.txt

@@ -12,9 +12,6 @@ From
 * http://agilewebdevelopment.com/plugins/tag/security
 * http://www.vaporbase.com/postings/Authorization_in_Rails
 
-
-== maybe ==================================================================
-
 * http://github.com/jbarket/restful-authorization/tree/master
 
 * http://agilewebdevelopment.com/plugins/rolerequirement

notes/SecurityPatterns.txt

@@ -0,0 +1,163 @@
+h1. Security from the perspective of a community site.
+
+Better than anything you'll read below on the subject:
+
+* "The OWASP Guide to Building Secure Web Applications":http://www.owasp.org/index.php/Category:OWASP_Guide_Project
+* "Secure Programming for Linux and Unix HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
+* "Core Security Patterns":http://www.coresecuritypatterns.com/patterns.htm
+* Stephen Downes' article on "Authentication and Identification":http://www.downes.ca/post/12
+
+h2. Snazzy Diagram
+
+!http://github.com/technoweenie/restful-authentication/tree/master/notes/SecurityFramework.png?raw=true!:http://github.com/technoweenie/restful-authentication/tree/master/notes/SecurityFramework.png
+
+(in notes/SecurityFramework.png)
+
+h2. Terms
+
+* Identification: Assign this visitor a name and an associated identity
+  (picture, website, favorite pokemon, trust metric, security roles).
+
+  bq. "Behold. I am not Gandalf the Grey, whom you betrayed, I am Gandalf the White,
+  who has returned from death." -- Tolkien
+
+* Authentication: Verify this visitor matches the claimed identity.
+
+  bq. "My name is Werner Brandis. My voice is my password. Verify me." -- Sneakers
+
+* Authorization: Given a request (Actions+Resource+Environment), decide if it's safe.
+
+  bq. "Of every tree of the garden thou mayest freely eat: But of the tree of
+  the knowledge of good and evil, thou shalt not eat of it: for in the day that
+  thou eatest thereof thou shalt surely die." -- Gen 2:16-17
+
+* Trust: Confidence this visitor will act reliably.
+
+  bq. "A copper! A copper! How d'ya like that, boys? And we went for it. _I_ went
+  for it. Treated him like a kid brother. And I was gonna split fifty-fifty with
+  a copper." -- James Cagney, White Heat
+
+** Reputation from Trust Network: Award trust to this visitor based on what other trusted parties say.
+
+  bq. "He used my name? In the /street/?  He called me a punk? My name was on
+  the street? When we bounce from this s-t here, Y'all gonna go down on them
+  corners, let the people know: word did not get back to me. Let 'em know Marlo
+  step to any m-f-: Omar, Barksdale, whoever. My name IS my NAME." -- Marlo
+  Stansfield, The Wire (paraphrased)
+
+* Reputation from Past Actions:
+
+  bq. "The man you just killed was just released from prison. He could've f-in'
+  walked. All he had to do was say my dad's name, but he didn't; he kept his
+  f-ing mouth shut. And did his f-in' time, and he did it like a man. He did
+  four years for us.  So, Mr. Orange, you're tellin' me this very good friend of
+  mine, who did four years for my father, who in four years never made a deal,
+  no matter what they dangled in front of him, you're telling me that now, that
+  now this man is free, and we're making good on our commitment to him, he's
+  just gonna decide, out of the f-ing blue, to rip us off?" -- Nice Guy Eddie,
+  Reservoir Dogs
+
+* Access control
+
+** Role
+  * http://en.wikipedia.org/wiki/Role-based_access_control
+  * "Role-Based Access Control FAQ":http://csrc.nist.gov/groups/SNS/rbac/faq.html
+  * "Role Based Access Control and Role Based Security":http://csrc.nist.gov/groups/SNS/rbac/ from the NIST Computer Security Division
+
+
+* Auditing & Recovery
+
+h2. Concept
+
+@  The below is a mixture of half-baked, foolish and incomplete. Just sos you know. @
+
+* Identity here will mean 'online presence' -- user account, basically.
+* Person will mean the remote endpoint -- whether that's a person or robot or
+  company.  (Security papers call this "Subject" but that's awful).
+* It's easy to confuse 'person' and 'identity', so easy I probably have below.
+
+Why do you need to authenticate?  For authorization. So traditionally, we think
+
+  person <- (ath'n token) <- identity <- (policy) <- actions
+
+That is, actions are attached to an identity by security policy, identity is
+attached to a person by their authentication token.
+
+The problem is that we cannot authenticate a /person/, only the token they
+present: password, ATM card+PIN number, etc.
+bq. "The Doors of Durin, Lord of Moria. Speak friend, and enter" -- Tolkien
+
+Anyone who presents that card+PIN, Elvish catchphrase, or voice print will be
+authenticated to act as the corresponding identity (account holder, friend of
+the elves, nerdy scientist), and we have no control over those tokens.
+
+  person <- (ath'n token) <- identity <- (az'n policy) <- actions
+        ^^^^ This step is wrong.
+
+The solution is to not care, or rather to reframe our goals.
+
+What we actually want is not to /control/ users' actions, but to /predict/ them.
+When Mr. Blonde helps Mr. White rob a jewelry store it's a security failure for
+the store but a success for the crime gang.  When Mr. Orange (an undercover cop)
+shoots Mr. Blonde it's a security failure for the crime gang and a success for
+the police.  We want to know how to use
+
+  ( identity, past actions ) => (trust, future actions)
+
+If you can predict someone is a vandal or troll, don't let them change pages, or
+only let them post to Ye Flaming Pitte of Flamage.
+
+We can to reasonable satisfaction authenticate a token: only grant that
+identity to visitors who bear that token.  So this part is fine:
+
+    person   (token)<- identity
+
+But we have no control over authentication token - identity correspondence.
+This part is broken:
+
+    person x (token)<- identity
+
+The only one who does have that control is the person behind that identity.
+They can reasonably guarantee
+
+    person ->(token)<- identity
+
+If that person is going to be in your community, they have an interest in their
+identity: they want to be known as someone who isn't a punk, or doesn't troll,
+or does troll and better than anyone, or won't rat you out to the cops.  The
+actions of a person are moderated by their interest in maintaining their
+reputation:
+
+    past actions -> reputation ->person
+
+So give up authorization in favor of auditing and recoverability, and authorize
+based on reputation -- on the past behavior and vouchsafes offered by the
+identity,
+
+    reputation -> trust -> permissions ->actions
+
+They want to know that they have full control of their identity; among other
+things, privacy and an understanding that nobody can act without permission on
+their behalf. In fact, we can assure that only a token-holder can assume the
+corresponding identity:
+
+    person ->(token)<->identity ->(trust) actions ->reputation ->person
+
+poop
+
+    reputation ->trust
+
+
+So we need to
+* Understand and encourage how their security interests aligns with ours,
+* Understand how it doesn't, and be robust in the face of that; and
+* Recover gracefully if it goes wrong.
+
+Instead of
+
+  authorization -> user -> token -> identity
+
+we assign roles based on
+
+  authorization <- trust <- reputation <- identity <- token <- person
+