Credential "Negotiation" Complexity

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

Hal,

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

I find this example strange.  If it is a "fact" that an Assistant Professor of Computer Science
implies a Phd in the same subject, why did not the AP provided the credential asked for?

Regardless of scheme used, all parties must agree on format and exact semantics of
credentials. 


Evan,

> But I think Anders has gotten to the kernel of this issue. I think for
> most of us with experience with AuthXML or S2ML, we've dealt from the
> get-go with expecting peer security systems to have arranged their
> partnership out-of-band. In other words, there are configuration
> options on each piece of software that say what data is sent as
> credentials, what profile information to share, what keys belong to
> what security system, etc.
> 
> We explicitly have this called out in the current doc, saying that
> "trust negotiations must be made out-of-band." I agree with Anders
> that there's a momentous opportunity in dropping this non-goal and
> allowing the trust relationship to be negotiated IN-band ("Who are
> you? Who says that's you? What do you want?").

I do not propose that we should solve all this IN-band.  It is largely impossible IMO.
Trust between parties (APs and RPs) will continue to be more or less out of band.

Regarding credentials, the parties must as already stated indeed support the same profiles.  This is
however something that does not always have to be performed using hardcoded, point-to-point,
out-of-band setups for each resource, URL etc.   That does not scale at all IMO!
If parties are able to define credential definitions that they can share, it should be about the same work
to define the run-time specification for the very same credentials.  This is essentially all I am asking for.
And I think (pardon me Bob M) that this is what Shibboleth is more or less depending on as well.
If Shibboleth is infeasible or if I got that wrong I would be happy [not so actually -:(] to know!

Anders