Re: ISSUE[UC-5-01:AuthCProtocol]

[Anders Rundgren <anders.rundgren@telia.com>]

Hal,

> Anders, I will make one more try and then give up.

There is no need to give up!  As Bob Morgan wrote Authentication is
a big word and we simply denoted authentication of two different entities.
Settled issue in other words.  No disagreements whatsoever.

<snip>

> I called this credentials negoiation and I believe a couple of other people
> independantly came up with same name. I again invite you to suggest a better
> one.

I may be stupid, but I don't see any "negotiation" going on here!

User through AP: I want to access "http://www.acme.com/projects/x.html"
RP: To do that you must be a "PhD in Computer Science"
AP: Creates a suitable "credential" if the AP-authenticated user is a PhD in Computer Science
    otherwise puts out  a message "Not authorized!"

Negotiation in my vocabulary indicates that there is some "trading" involved.

You also lack a business case.  Why do you need a particular business case when we are talking
about extending the access system of practially all computer systems (but with arbitrary
granularity and semantics) to function over the web between different, independent and
constantly changing organizations as well?
IMO that's *hell* of a use case!  If it is a hell to design I am not yet able to tell.

One major reason to the extended scheme I propose, is that the current [rigid] approach
seems to leave credential incompatibility issues in the hand of the user instead of the AP.
It *may* cost an extra "round", but it will put much less burdon on helpdesks.  It is BTW a true
superset of the other scenarios.  Security-wise it can (compared with the other Push case)
handle encrypted credentials (essentially only as issue with POSTed HTML creds) much
better as the most recent RP public key is always at hand.  And if credentials really are
sensitive I think that RP auth is not such a bad idea (host may hold different partners
so DNS is not always enough). And then we have the privacy stuff as well.  So it is
no so much about particular business case, rather it is about designing a system that can be
used in as many places as possible, and does not suffer from obsolence 6 months
after launch.

<snip>

Anders