WAC-Allow's access-mode parameter to allow any term

[csarven]

To enable a wider set of access modes that can be used in the WAC-Allow header field-value, the access-mode parameter should be relaxed to allow any term. WAC-Allow's current definition uses:

access-mode = "read" / "write" / "append" / "control"

Proposed change would allow any term:

access-mode = 1*ALPHA

where the terms are defined in their own spec eg. the WAC spec defines "read", "write", "append", "control" as clear mapping to the terms in the ACL ontology eg. "read" for acl:Read. When new access modes eg. acl:Create are defined and terms such as "create" are mapped to them in a spec, they can be used by implementations conforming to those specifications. (Unrecognised terms are strongly encouraged to be ignored.)

This change also makes it possible for other authorization systems using access modes to define and map terms in their respective specification. See also solid/specification#210 (comment)

[timbl]

I feel that if the WAC-Allow allowed strings are to be extended, then it is important that the meanings of the strings are defined. This is a standard protocol. If we need to add "delete" etc then let's define what "delete" does and does not mean. People write code which generates these things and looks at this header which does useful things. Leaving it as allowing random strings would be a mistake.

[timbl]

It will be important to establish mappings between WAC and ACP modes. It is important to do that anyway. The existence of the universal API suggests that mapping is possible and important.

[csarven]

Provided that we have consensus on the finite set of access modes that can be used by different authorization systems. See also Access Mode Extensions: #85

[csarven]

If WAC-Allow is defined in the Solid Protocol ( solid/specification#277 (comment) ) as opposed to the WAC spec, then we can do two things:

• Solid Protocol can define the WAC-Allow access mode strings to correspond to the operations in the Protocol (currently it includes read, write, append, but there is also one open issue to define it for delete... and we can have more eg. create, modify.. controlread..)
• WAC spec maps the Access Modes from the ACL Ontology to the access mode strings in WAC-Allow. Ditto other authorization systems using different vocabs.

[kjetilk]

I agree there should be a closed world here, and I think we can reasonably do this in the protocol spec so that it becomes independent of the access control system.