Re: AccessControl : update + inference

On 15 November 2012 03:51, Michiel de Jong <michiel@unhosted.org> wrote:

> right - of my questions
>
> 1) how does Bob send his credentials
> 2) how does Alice's web server check them
>
> Cookies, client-side SSL certs, unguessable URIs, client IP, http
> basic/digest/bearer auth, etcetera answer question 1.
>
> WebID, Persona, OpenID, etcetera answer both question 2 and the extra
> question:
>
> 3) how does Bob obtain his credentials in the first place.
>
> the wiki page we're discussing is, or at least was, mainly about:
>

Provisioning of credentials in the first place, seems to be similar to a
traditional sign up / sign in process, I think?

After that you can use something like a cookie (eg an unguessable shared
string)


>
> 4) how does Alice's server remember which credentials should give
> access to which actions.
>

Alice will have a persistent store of who can access what

The key thing is that Bob must identify himself.  He can do this
unambigously, given his unique URI.  Or he can do this more obliquely with
a non universal identifier.  e.g. on the phone he'd say "Hi, it's Bob".
This is fine for a small scale scenario, but you run the risk of name
clashes and scalability issues when you do not use a namespaced identifier
such as a URI.

>From the identity you can determine access.  Importantly, some pages may
not require any auth at all, e.g. the login screen.


>
>
> Those questions 3 and 4 can be related if the credentials Bob uses
> come from Alice's server. OpenID, Persona and WebID are interesting in
> that they use credentials that Bob's server issues, and Alice's server
> merely points at Bob's server when representing which credentials give
> access to which actions, and that is then finally how
> identity/authentication comes into play. But to me the credentials as
> such are more "basic" than the identity; at the time of the request
> it's the credentials that give access, whether or not the client
> obtained them in a "legitimate" (in terms of identity) way.
>

The web is all about following pointers to get more information.  So this
is valid.  Some people still like to use email as an identifier, but it's
very hard to follow your nose with email.  As the web grows hopefully HTTP
will become more often used in this respect, as an Identifier.  HTTP has
the advantage that it was designed to be dereferecable, scalable and fault
tolerant.


>
> On Thu, Nov 15, 2012 at 5:47 AM, Jan Wrobel <wrr@mixedbit.org> wrote:
> > On Tue, Nov 13, 2012 at 11:50 AM, Melvin Carvalho
> > <melvincarvalho@gmail.com> wrote:
> >>
> >>
> >> On 13 November 2012 02:18, Michiel de Jong <michiel@unhosted.org>
> wrote:
> >>>
> >>> i feel the LDP page misses the point. it describes ways in which you
> >>> can use, say, an Oracle database, to describe if certain credentials
> >>> which the client sent are sufficient for a certain action or not. What
> >>> they don't describe is how the client can actually send these
> >>> credentials, and how the server can check their validity.
> >>>
> >>> Let's look at the basic use case first: Alice has a website, and Bob
> >>> is allowed to edit it.
> >>>
> >>> No irrelevant things about 'Bob is within a 500m radius of a certain
> >>> geo location' or 'Alice uses an Oracle database to run her website'.
> >>> Imho that misses the point. There is a small note at the bottom of the
> >>> LDP page saying "identity: WebID". That is what we should be looking
> >>> at, i think:
> >>>
> >>> 1) how does Bob send his credentials
> >>> 2) how does Alice's web server check them
> >>>
> >>> For this, i'm aware of the following options:
> >>>
> >>> - username/password (doesn't scale of course if Bob has many friends)
> >>
> >>
> >> Username / pw is really what got the web going, but the issue is
> security
> >> and password fatigue.
> >>
> >>>
> >>> - WebID (favourite of this CG!)
> >>
> >>
> >> I would hope we try to be neutral to an extent, and not pick
> favourites, but
> >> WebID does have a lot of appealing properties, for those that are linked
> >> data oriented.
> >>
> >>>
> >>> - OpenID (sadly probably deprecated)
> >>
> >>
> >> I followed OpenID from almost the start, am a huge fan, in that they
> changed
> >> the conversation from being about walled gardens and passport, to about
> >> trying to be open.  I had been looking forward to the user centric
> elements
> >> of openid, but there is little business case to interest the foundation
> >> there, which I can accept.
> >>
> >>>
> >>> - Persona (promising imho)
> >>
> >>
> >> Indeed very promising.  Great UI and lots of buzz.  A couple of things
> I'd
> >> love to see in persona, is that it becomes an identity system that can
> >> easily interoperate with other identity ecosystems, tho that's not
> currently
> >> on the roadmap.  Similarly they take a reasonable stance of saying 'your
> >> email provider can read your mail already, so they can already access
> your
> >> external data'.  This seems an acceptable compromise for the majority,
> but
> >> some security conscious folks may prefer not to use it for sensitive
> data
> >> such as financial transactions.
> >>
> >>>
> >>> - Dialback (same)
> >>
> >>
> >> Some buzz around this one, dependent on webfinger, which seems to change
> >> from month to month.
> >>
> >>>
> >>> - Salmon (specific for blogpost-comments, and probably deprecated by
> >>> dialback?)
> >>
> >>
> >> A nice system, but it seems everyone implements it a different way.
> >>
> >> Also dont forget
> >> - Cookies
> >
> > I'm not sure if cookies belong to the same category. Aside from WebID
> > and HTTP basic and digest auth many mentioned mechanism depend on
> > cookies. OpenID or Persona (I don't know about Dialback and Salmon)
> > are used to authenticate the first request and then cookies are used
> > to associate following requests with the authenticated user. So
> > cookies are rather used to persist authentication info not to
> > authenticate.
> >
> > Cheers,
> > Jan
>