Shibboleth Developers

["Scott Cantor" <>]

> Just to clarify, non-browser cases do not "require that we support proof
> keys" any more than the web browser case does.  Some people feel strongly
> that the security benefits of tokens with proof keys should be available
> to apps that want to take advantage of them.  As far as I can tell the
> security interest isn't particularly dependent on the app protocol between
> Infocard client and RP.

Well, it is in the sense that the browser case has been engineered and
profiled by Microsoft to literally disallow proof keys. Unnecessarily, as
best I can tell, but be that as it may...

So if we do only web, there is no need to handle holder of key as a possible
option for an IdP to issue. If we do more than web, then yes, I think it's a
darn good idea to support holder of key, which also supplies some code that
may be useful to other SAML or non-SAML profiles. But it's a lot of work,
potentially.

> Just to clarify, this means supporting self-issued cards as an
> authentication method to the IdP.  This is really just integrating an
> Infocard RP into the IdP.  The handling of key/PPID as user identifier is
> something any Infocard RP supporting self-issued cards has to do.  The
> additional consideration at the IdP is mapping this to existing user
> accounts, aka registration.

Per the call today, it's a possible interim step to require a Shibboleth SP
in front of the IdP via the REMOTE_USER login handler, but that would make
Apache a requirement as well of course.

> In my organization I see Infocard as an IdP authn method as likely being
> more useful in the near term than managed cards (issued by the IdP and
> consumed by app RPs), though obviously the latter is where the real
> promise of Infocard lies.

Definitely have heard mixed opinions about this, especially since CSv1
doesn't support requiring a PIN on self-issued cards. So do we want people
registering cards that basically make their desktop a permanently
"signed-in" client for SSO? Probably some people would say sure, e.g.
Kerberos sites.

Anyway, obviously we don't have to judge this other than to decide how and
when to deliver such support.

> To the extent that there is anything in Infocard material saying who is
> supposed to trust whom (very little, to my knowledge), the common use case

The profiles are definitely written in a manner that strongly communicates a
model in which the IdP is not a vehicle for controlling what the user does
or where they do it. That doesn't mean you can't, but it says to me that
we'll be arguably alone in doing so for now, and may run into limitations if
we push any spec boundaries in trying to do it.

When I wrote up a SAML profile, I took some pains to try NOT to push too
many boundaries.
 
> is the consumer case, where the IdP has essentially no organizational
> policy but is just serving the user's interests.  But I don't think this
> in any way is intended to tell organizational IdPs that somehow they are
> not permitted to have policy about what they send.  That would be absurd.

It's not so much about what you send, but were you send it. That's something
we're trying to reconcile with the standard SSO model in which where we
allow the client to go is largely IdP-mediated so as to allow for some kinds
of policy enforcement.

> > -- Shib ARPs were designed to allow the filtering of multi-valued
> > attributes. CS doesn't provide any such filtering. A card might say
> > "release entitlement" -- does that mean we release every value?
> 
> No more than the IdP would release every value if a SAML RP asked for an
> entitlement attribute.  Policy-based filtering is done by the IdP
> implementation in either case.

Yes, but it definitely makes any dynamic use cases where the user decides
much harder. Probably doesn't matter for entitlement, but might be something
to watch for as we look at other future attributes we invent. Or we just try
and get MS to implement value discrimination, which I think they plan on,
but that's harder when you're not requiring specific token formats.

-- Scott