Shibboleth Developers

[Scott Cantor <>]

> This model assumes, in Shibboleth terms, that the user's Origin 
> Domain is the domain of the target service (step 1 above).  The twist 
> is that the Origin Domain is not authoritative for at least some of 
> the attributes of interest.

I think it's quite tractable today with attribute acceptance policies that
finely control which values you accept from whom.

>  From a Shib point of view, the "target" in this case wants to be able 
> to ask a particular AA at any point in time to release information 
> about some entity.  There is an assumption that the target has an 
> identifier of some sort for the subject that is recognized at the AA 
> -- the cert Subject Name may or may not be that identifier, depending 
> on how it was created.  So the subject identifier is the first 
> problem. (+)

Why is that a problem? The AA has factories for different types of names and
Walter is extending that now. And adding ARP support for controlling release
based on the type of identifier...

> The second problem is simpler: a different API to the AA.  This would 
> be a simple query interface where the asker is identified by means of 
> a trusted cert (no mean feat but that's another story).  As with any 
> query to the AA, there is default information that it will release to 
> any asker but if the asker is "known" to the AA, then it may have a 
> specific ARP to apply to the query.  Again the crux is the identifier 
> by which the asker seeks to be recognized.

This isn't a different API, we support this today. How do you think the
requester is authenticated today? (For a hint, see the recent USC
problems...;-)

Basically all of this supported, it's just not fully cooked into the ARP
model yet, nor do we yet support a single AA easily supporting multiple
identifier types, but we're working on it.

> >* Handle is placed into signed authn assertion along with user's
> >subject name. Lifetime of handle and authn assertion is set equal to
> >lifetime of user's credentials (probably with some administratively
> >set maximum). Authn assertion is returned to user.
> 
> Sounds like a Kerberos ticket ...

Sure, Kerberos is just a little hard to federate.

> All this primarily to avoid a new API at the AA.  I think we've 
> always known that a simple query API is needed so that needs to be 
> designed anyway.  So the question is whether any of the other 
> trust-related pieces of this scenario add something useful.

Nothing really all that new here.

>   - is the concept of "session" important WRT the simple query API? 
> In other words, is there a concern that a query should be the result 
> of a user action and not an arbitrary, random event initiated by the 
> target?

We've discussed it. We're not fully set on how to repesent this in the ARP
yet. We've debated a really simple binary Presence/NoPresence vs. more
complex approaches.

>   - is there any serious impediment to a simple query API for the AA?

Maybe you need to define "simple query API" and I'm not getting it. I don't
think we'll ever want to really look at true search filtering. That's what
the back-end LDAP/RDBMS store is for.

-- Scott