Shibboleth Developers

[Scott Cantor <>]

>  If I roughly summarize your last few notes, your basic gist is that
> the shib handle makes solves the inter-organization authentication
> problem and the Grid should use it instead of bringing DNs into the
> Shib space.

I heard David arguing for use of EPPN, which is just a different global
identifier that happens to be more readily understood by a lot of the Shib
pieces today. Handles don't have any "realness" apart from a transient
dialog between SAML components.

>  Second, many in the Grid community are going to have a problem with a
> bearer credental (which is what I understand the shib handle to
> be). They will want to have a binding back to a key proven to be in
> posession of the user.

The handle is not a credential at all, except perhaps in the sense that the
SHAR uses it as its "user presence proof" to the AA, along with its stronger
credentials. It's definitely not a credential to the user. The SSO assertion
and profiles defined by SAML use a signed assertion as a bearer token,
because the goal is not to require a private-key-capable client. But the
handle has nothing to do with that, it's simply payload.

If you have that key and a way to prove posession in your application
protocol, I think we're comfortable using it in some fashion in SAML. It was
mentioned in some detail on the last call, matter of fact.

> 1) User authenticate to local service, very similar to the exiting
> handle service, and gets back a handle. Handle is also put into shib
> AA as it would normally be done today.
>
> 2) User bundles handle with Grid credentials, authenticates to target
> service (by bundle, I probably mean stick in as noncritical X.509
> extension, but that a detail).
> 
> 3) Target service takes handle, basically acts like a SHAR - it
> contacts shib AA with handle and everything proceeds as it normally
> would with Shib today.

All you're doing is substituting X.509 here for SAML. There's no SAML
authentication authority here at all, thus no HS either. You're just saying
you want to get a reference to talk to the AA with and stick it in an ASN.1
token. Fine by me. Would that X.509 had worked for anyone else. ;-)

> So this is pretty similar to Shib today, the only difference being
> that instead of the SHIRE and browser redirection to get the handle,
> the user contacts some modified handle service first and bundles it
> with their Grid credentials.

No, I think it's more accurate to say you're using a non-SAML mechanism to
deal with federating the authentication (X.509) and then bridging that to
the SAML attribute authority as an application detail. That's fine, but I'm
not sure there's much for us to do. We don't generate X.509 certs, so that's
not a HS you're describing, modified or otherwise. Does that make sense?

> Now let me add one twist - Add something to the handle to accomodate
> the "identity" of the user. The modified handle service above could
> stick that identity into the handle and a target *who cares* can
> verify ownership of the handle and hence get a path back the posession
> of the private key (my second point above). Note that a target that
> does care (for whom a bearer credential is acceptable) can skip this
> step and treat the handle opaquely.

I think you need to step back and not think of the handle per se as any sort
of credential. It's a name, just like a DN is a name. It has different (and
short term) properties, but in all other respects it's a name.

-- Scott