shibboleth-dev - RE: AA issues to be discuss at next meeting
Subject: Shibboleth Developers
List archive
- From: "Scott Cantor" <>
- To: <>
- Subject: RE: AA issues to be discuss at next meeting
- Date: Mon, 29 Oct 2001 17:18:26 -0500
- Importance: Normal
> 1.) How does a failure of one or more backend services being queried
> by an attribute method affect AA response? Eg.
> If the AA needs to query an LDAP server to determine an
> attribute value and the LDAP server is not available what should the AA
> provide in the response?
> a.) should it just return the attributes which methods succeeded?
> b.) should it just return an error condition with no attributes at
> all?
There's more about error handling in the 3rd draft, but this specific
question isn't addressed. I'd say it's an implementation decision, but maybe
there should be a more consistent approach...It's a good question.
> 2.) Any UI will need a method of generating all possible attributes to
> provide a friendly interface. I assume we need to build an API to
> enumerate all possible attributes there are methods for. Comments?
Yes, I sort of envision a "registry" of attributes for a given AA and a
given SHAR (this is the namespace idea the Leeds folks have) where you can
enumerate the plugged in attribute classes that would apply to that SHAR.
Registering the attribute's class might include giving it a name, a
description, etc. Anything needed to help implement the UI, really. This is
one reason I like this approach over just thinking about LDAP or a database
interface directly.
It might be the case that you only display a subset of attributes that are
designated "privacy sensitive" too, I dunno. One could argue that a contract
1234 attribute is not privacy sensitive, but if the provider knows the
contract language is "law student" means "yes", then you're effectively
telling the provider exactly that, so maybe everything should be
controllable...
> 3.) What should be the maximum number of attributes assumed to be?
> (just the order of magnitude we should implement for)
I think it has to be manageable. The set of universal attributes should be
"not huge", and the custom attributes will probably be just a few yes/nos or
access classes per contract/site, I would think.
> 4.) What is the syntax that will identify an authenticated user?
In the sense of displaying it? I guess it would look like EPPN?
-- Scott
------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at
http://archives.internet2.edu/
------------------------------------------------------mace-shib-design--
- AA issues to be discuss at next meeting, Russell J. Yount, 10/29/2001
- RE: AA issues to be discuss at next meeting, Scott Cantor, 10/29/2001
Archive powered by MHonArc 2.6.16.