[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: enrollment/mgt operations
I think there should be some clarification of the management issues. Some
queries I have are ...
Are there plans to provide delegated credential access. An example could be
that a manager could be given access to the team members credentials or a
secretary could read and decrypt mail for the person they work for. Also
there should be the ability to make an entity a retrieval authority such as
a system admin or high ranking company employee.
Also what about scenarios of revoking access to credentials for an entity
but still allow the credential to be retrieved by another entity or
authority. This could happen in a company when an employee leaves the
company but their correspondence still needs to be accessible by an existing
member of the company.
Registering a new entity onto the system may warrant its own function. Many
things could be configured at this point such as authentication method for
that entity and also it provides a point at which an admin person can
actually reject or allow an entity access to the system. There might be
other situations where there already exists a compant entity registration
database which is to be reused so the user registration will not
neccessarily happen on the first credential upload.
-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxxxxx]
Sent: Saturday, 28 October 2000 0:29
To: ietf-sacred
Subject: enrollment/mgt operations
Hi All,
I'm looking through the comments we got on the requirements and
would like to get some opinions about how much detail to include
(in the requirments document) about management operations.
Right now, there's just a generic requirement that the
protocols must support mgt operations. Self-enrollment was
mentioned on the list and should at least get a mention too.
I guess the overall list of operations might be something
like:
GET for downloads from a CS
PUT to update/change a credential or direct transfer one
ENROLL could be a special case of PUT?
DELETE to zap a credential (carefully:-)
So, questions:
- Should the requirements document specify these separately,
each with associated MUSTs etc?
- If yes, then what other management operations might there be?
(e.g. do we need an interoperable form of DISABLE/ENABLE to
temporarily make credentials unavailable, MODIFY to change
an existing credential...)
- Does all this just apply to the credential server case, or
also for direct transfers?
Regards,
Stephen.
BTW: Dale and Magnus have taken on drafting a framework document
(thanks guys:-) so we should have one to discuss in San Diego if
they manage to make the cutoff.
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane, fax: +353 1 647 7499
Dublin 2. mailto:stephen.farrell@xxxxxxxxxxxx
Ireland http://www.baltimore.com