Skip to Content.
Sympa Menu

shibboleth-dev - RE: A Case for Shibboleth and PKI (again)

Subject: Shibboleth Developers

List archive

RE: A Case for Shibboleth and PKI (again)


Chronological Thread 
  • From: "David L. Wasley" <>
  • To: "Shibboleth Developers" <>
  • Cc: "'David H. Walker'" <>
  • Subject: RE: A Case for Shibboleth and PKI (again)
  • Date: Sat, 1 May 2004 19:05:33 -0700

Agreed. Since it's not a scoped "handle" it is potentially dangerous and therefore should be treated as such in ARPs.

Thanks,
David

-----
At 9:09 PM -0400 on 5/1/04, Scott Cantor wrote:

> I think the general case of a "portable handle," in spite of reduced
privacy, has value as an extension to the basic model of
"authenticate locally; authorize globally". I think there may be a
number of cases where the user may not be able to communicate with
their local authN system but the target server could.

It's important to note that if the target server trusts the credential and
then happens to extract something out of it and sends it to some other
service to map it to additional information, that's still a case of
authenticating directly to the target, and not analagous to the SAML browser
profile.

The reason I referred to the cert subject name as a "handle" is to
reinforce the notion that it serves approximately the same function
as the Shib handle. I think this may have some implications for the
subject name content as well as for the AA API.

It doesn't have any implications for the AA because it is in fact what you
say, just a subject name. As is a "handle" in Shibboleth. The AA doesn't
know or care anything about the subject name format, that's a completely
pluggable decision. It knows nothing about handles today, for example, only
the small bit of code that tells the AA what principal name corresponds to a
handle knows anything about them.

I also thought the x.509 object would be rather easier to deal with
as opposed to almost any other form of portable credential.

I don't disagree, just noting that if the numerous limitations of client
software are such that it creates a problem for users, it's not clear
there's much of an alternative.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page