[cap-talk] [Fwd: Re: What we have here is a failure to communicate]

[Rob Meijer]

On Wed, December 31, 2008 08:15, Jed Donnelley wrote:
> At 02:16 PM 12/29/2008, Rob Meijer wrote:
>>On Sun, December 28, 2008 06:46, Karp, Alan H wrote:
>>...We should actually try to make clear that authentication IS a
>>broader concept,
>>and that authenticating, for example your SAML assertions, is just as
>> much
>>an act of authentication as authentication of subject identity.
>
> Hmmm.  If there is an intent to use the term "authentication" for more
> than
> "subject authentication" then I'm afraid I don't know what that additional
> meaning is.  I thought AlanK's SAML assertions were "authorization based
> access control".  That is, they are explicitly 'authentication free'.
> Is there anything in the SAML assertions that demand a specific subject -
> beyond of course the possession of a capability-like token?  I admit to
> little understanding of the SAML assertions, but if they can be used as
> an example of authentication that isn't "subject authentication" then I
> would like to better understand that mechanism and meaning.
>
> At 09:07 PM 12/29/2008, Karp, Alan H wrote:
>>Rob Meijer wrote:
>> >
>> > I feel it is important to not fall into the identity bias trap by
>> > limiting discussion of authentication to the authentication of
>> subject identity.
>> > We should actualy try to make clear that authentication IS a broader
>> > concept, and that authenticating for example your SAML assertions
>> is just as
>> > much an act of authentication as authentication of subject identity.
>>
>>I agree, but I think we need to be explicit.  When I use the term
>>"subject authentication", I am making it clear what aspect of
>>authentication I mean.  It's why we use the term "object
>>capabilities" (a term first used only recently), to make it clear
>>that we're not talking about special hardware registers or some
>>other form of capabilities.
>
> It would help me to have some examples of other 'aspects' of
> authentication besides "subject authentication".  Are you (both)
> referring to the general definition of "authentic"?

A few examples I have been using as example where not subject identity but
some other thing needs to be used in the authentication phase as source of
authority and needs to be authenticated prior to this:

1) I can write out and sign a bank check payable to anyone. I can give you
that check, you can again give it to someone else who can go to the bank
and get it payed out. For access control purposes the bank will authenticate
the check and signature, but not the subject identity.

2) I can go to the train station, pay a small amount and rent a storage box.
I will get a key to the storage box in exchange for my payment,
I can give you this key, and you will be able to open the box at the train
station. The storage box console will authenticate the key, but not
the subject identity.

The signed bank check and the key are sources of authority by their own
right without any coupling to "subject identity", but they do require
being authenticated.

In the example of the bank, the bank may still want to authenticate the
subject identity as to establish a "source of accountability" for purposes
of logging and possible future incident response, but that action would
not be required from an access control point of view.

>From this I've come to the conclusion that there are two basic types of
authentication:

* Authentication of a source of authority.
* Authentication of a source of accountability.

In many systems both are subject identity.

Rob