Shibboleth Developers

["David L. Wasley" <>]

Hmm... deja vue all over again.
-----
At 10:48 AM -0600 on 1/15/04, Von Welch wrote:

>  > 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.
>
> No, just that the target service accepts identity credentials from the
> user's origin domain (e.g. it trusts the CA that issued the user's
> EEC).

But this is exactly the problem that Shib was invented to solve: 
inter-domain inter-operable credentials are hard.  Instead, let the 
user's "home" domain understand the credentials and then provide 
authoritative information about the subject to the target.  That's 
the function of Shib.

>  >  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. (+)
>  >
>  > 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.
>
> Right. I think we've had discussions in the past if Shib could use a
> Subject name instead of a handle. The answer I believe I've gotten is
> "yes with some work".
OK - I was not going to raise this but I guess I need to: what is in 
the SubjectName field of a user's "home" campus cert may or may not 
be useful in a query to the "home" AA.  And if it is, what part of it?

For example, the UC certificate profile defined SubjectName as
        C="US"
        O="University of California"
        OU="<campus name>"   e.g. "Berkeley campus"
        CN="<UC NetID>"  which is a large integer unique to the individual

Whereas the UC campus Handle Server interface needs to understand 
this credential, the AA interface (currently) only understands the 
HS-generated handle.  Clearly SMOP but ...

The same person's EPPN might be "" and I would 
assume that a query to the AA for attributes based on this EPPN would 
be straight forward.

I suppose we could assume that a campus run AA could be programmed to 
accept a campus generated cert full SubjectName as a query key.  At 
UC, all we'd need is the CN= but we I don't think we can assume this 
would be true everywhere.

Just want to make sure this assumption is on the table.

        David