[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Additional operations
Menno Pieters wrote:
> At 12:04 PM 3/27/01 -0600, Tom Jordan wrote:
> >Are there any plans for an administrative commandset that would work
> >across implementations? If the administrative interfaces for SACRED are
> >vendor dependent, it will be hard for administrators to manage credentials
> >across different servers/devices.
> While going through my mail archive I couldn't figure out whether it has
> been mentioned before, but I could imagine that a new credential to be
> stored on a credential server is accompanied by a descriptive header or
> Such a header/attachment could include some administrative tags (lock,
> unlock, access-lists). Would it be a good idea to use [multipart/]mime
> format to pack a credential and accompanying information? If I'm not
> mistaken, XML has also been mentioned before in such context.
I think lock/unlock has already been addressed.
We intend to use (HTML and) XML to encode the transactions exchanged between
client and server when http is used as the transport layer protocol. The
Framework has been extended to allow support for additional transports such as
UDP, TCP, and BEEP. Perhaps others could comment on the viability of using XML
over other transports.
I assume we will use a well defined (profiled) subset of the chosen credential
format's capabilities within SACRED. Additional information exchanged between
clients (if needed) could be included within the credential (using PKCS-9
attributes inside a PKCS-12 credential, for example). Additional info.
exchanged between client and server would most likely be included in the XML
encoded data (outside the credential).
> Requirement F4 in the requirements draft states that the format MUST be
> opaque to the protocol, though not to processing in the protocol's peers.
> That would allow for extra information to be processed by a server, store
> or device, apart from the sacred protocol.
> Menno Pieters
> >If I have to touch several different interfaces to lock a user's
> >credentials due to the fact that the admin operations are vendor
> >dependent, it seems as
> >though the utility of the protocol is somewhat diminished.
> |Menno Pieters |
> |M&I/STELVIO bv |
> |Zonnehof 41 |P.O. Box 2171 |
> |3811 ND Amersfoort |3800 CD Amersfoort|
> |The Netherlands |The Netherlands |
> |Phone: +31(0)33-4697340 |
> |Fax: +31(0)33-4697341 |