OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

[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