RE:[UC-1-04:ARundgrenPush] was ISSUE[UC-5-01:AuthCProtocol]

[Hal Lockhart <hal.lockhart@entegrity.com>]

Anders,

> 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.

This is negotiation in exactly in the sense that protocols like SSL and IKE
allow negotiation of encryption and hash methods. In the standard case, the
AP unconditionally issues whatever credentials it feels like. In the
advanced case, the RP says what it wants and the AP (presumably) takes that
into account in generating the credentials.

Let's look at you example a little, because it illustrates some of my
concerns. First of all, if the RP says "can Joe access x.html?" and the AP
says yes or no, this is the PDP to PEP case we have been talking about for
some time, with which I do not take issue. (Although I question its
practical utility.)

> 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.

What I said was "Additional design complexity must be justified by stating a
specific business requirement that cannot be met by the first scheme that
can be met by the second."

I don't think I see that yet. But I will let the rest of the TC judge.

> 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.  

Here I respectfully disagree. Consider your example:  the RP says: "must be
Phd in Computer Science." Suppose the AP sends credentials saying "Is an
Assistant Professor of Computer Science" Now RP "ABC" is smart enough to
know that the latter implies the former, but  RP "XYZ" is not. The user gets
rejected by "XYZ" and can't figure out why. The AP says "my credentials are
perfectly good. "ABC" accepted them." But "XYZ" says I didn't get the
credentials I was looking for. I bet that will take the helpdesk a while to
sort out.

>It is BTW a true
> superset of the other scenarios.

I am not sure what you mean by this, but as I mentioned in my previous
message, at least in some cases, it cannot be made transparent. The AP has
to decide whether to issue creds unconditionally or ask the RP for info.

>  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).

I don't understand this at all. It seems to assume design elements
(possesion of public key) that are not evident in the usecase.

> And then we have the privacy 
> stuff as well.

As I pointed out, you can give the user control of what is exposed in the
static scheme 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.

Here is a real point of disagreement. We are not designing a system. We are
defining a standard. I think we need to be really cautious about designing
complex features with no deployment history, unless the requirements show we
cannot do without them.

Regards,

Hal