- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Mon, 16 Oct 2006 06:52:02 +0100
- To: Manuel Gil Perez <manuel@dif.um.es>
- CC: www-xkms@w3.org, Michael Wilde <michael.wilde@yahoo.de>
Manuel Gil Perez wrote: > > Dear Michael, XKMS folks, > > X509v3 certificates cannot contain any privilege (in your case, a role > name) belongs to an end identity. A X509v3 certificate only links > statically a public key with a specific identity, not privileges. For > fix this "problem", IETF-PKIX WG defined a new structure called "X.509 > Attribute Certificate" (RFC 3281) to associate privileges to a specific > identity. The section 4.4.5 of that RFC defines how define/include a > role name. Attribute certificates existed well before the PKIX profile and are part of X.509. There is also no reason at all why a public key certificate cannot contain privilege data like roles - sometimes that's better and sometimes its better to use an AC. > IMHO, my advise is that we/you should try to extend the current XKMS > services to support this new kind of certificates, and so provide a new > PKIX service (privileges) to the users. Disagree. The xkms client must not have to know whether there's any X.509 PKCs or ACs anywhere, or else why are you using XKMS? So while it does make sense to think about including/linking simple privilege data to XKMS it does not, IMO, make sense to try "support" X.509 ACs in XKMS. If you want that kind of privilege handling use SAML. Regards, Stephen.
Received on Monday, 16 October 2006 05:51:39 UTC