Comments on draft-sstc-core-vmodel-03v

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Title:

Hi Phill,
I have a few comments on your latest document.

 

I think we need to give more consideration to what attribute
assertions that authorize access to groups of resources look
like. Currently the document proposes URI to identify a resource
(i.e. a URL) or some rights identifier (a URN) to denote rights (or
roles) like plumber.

 

On today's teleconference it was briefly mentioned that the most
common model will be authorization for groups of objects or
folders. How this is supported in the model is not yet articulated.

 

Enumerating every single resource is not scalable or convenient. I
think it is also going to be inconvenient to insist a rights
identifier is always used to denote authorized access to groups of
resources. If that were the case we would have a different model for
singleton resources (they are identified directly) to groups of
resources (they are denoted implicitly). In the implicit model is up to the application
(PEP) to interpret what group of resources is denoted - it may not be
exactly the set of resources the issuer of the assertion had intended.

 

I suggest we consider an explicit syntax for denoting resource
sets. Otherwise we could end up with some ambiguous situations. For
example what is the meaning of an assertion containing the URL:
http://foo.bar.com/docs/

 

Is it access to the document displayed when you request this URL? Is
it access to all documents below this point on the web server? One
option is to leave the PEP free to decide on the semantics of this. I
don't like that option, as it could lead to accidental or unintended
authorizations.

 

I suggest we could explicitly denote the set by introducing a prefix
element, whose intended semantics was any URL prefixed by the given
string: <prefix>http://foo.bar.com/docs/</prefix>

 

Wildcards might also be useful (e.g. to specify things like *.txt),
but I haven't thought of how to do that.

 

I couldn't understand the purpose of the claim/authority/advice
elements. Maybe some more examples would help. Or perhaps you could
explain on the next teleconference. Sections 4.2.7 (Element <Claim>)
and 4.2.8 (Element <Advice>) seem to share the same introductory text
(with "claim" substituted for "advice" in 4.2.7).

 

Other comments

 

Figure 2: I think to be consistent with the domain model, you need to
relabel "Issue Point" to be "Attribute Authority".

 

I think they may be some cut and paste problems in sections 4.2.3 and
4.2.4: the element name is the same in both sections.

 

Regards,

Nigel.