[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Addition to interim requirements
Phill I agree both with capturing the requirements, and, at least in the case of revocation, not supporting. Revocation is as we all know a complicated issue, and I'd rather not tackle it again here. I think if you want a revocable credential you could simply form an assertion that a particular X.509 cert or PKIX AC (referenced by a URI for example) belongs to a subject, and depend upon the existing revocation infrastructure. Another possibility would be to deal with issues of timeliness and validity either in the protocol binding (in the case of timeliness) or in the evaluation logic at the PEP/PDP receiving the assertion. --bob Bob Blakley Chief Scientist, Security Tivoli Systems, Inc. Philip Hallam-Baker <pbaker@verisign.com> on 01/29/2001 04:38:43 PM To: "'Edwards, Nigel'" <Nigel_Edwards@hp.com>, "'security-core@lists.oasis-open.org'" <security-core@lists.oasis-open.org> cc: Subject: RE: Addition to interim requirements Another set of 'requirements' to add are the ability to withdraw credentials (time out / revocation) [R-Limitation] Ability to limit the scope of a credential. [R-Revoke] Ability to revoke a credential after issue. Now I don't think we necessarily want to provide the architecture to support them BUT they are potential requirements and we should probably say we don't support if we don't support... I will issue an updated doc sometime this week based on all submissions to the list. I think we are making progress here, the real tricky part will be normalizing the nomenclature and terms which we will have to come round to soon. We will end up with several pieces of data that can be sent / recieved and have to give them names (credential/entitlement/ whatever). Problem being that all the best terms tend to be 'loaded' - capabilities, rights, permissions for example. Phill > -----Original Message----- > From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com] > Sent: Monday, January 29, 2001 9:29 AM > To: 'security-core@lists.oasis-open.org' > Subject: Addition to interim requirements > > > I'd like to propose another "interim requirement" for the assertion > group. > > [R-AuthorityScoping] Support for scoping for what assertions an > authority is trusted > > For example, I might want to allow a third party to issue assertions > granting POST access to part of my web server (but not the whole web > server). Another example would be to allow a third party to issue > assertions granting access to a subset of the operations available in > a particular (CORBA) interface. > > Nigel. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC