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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] REST Profile wd04


>>>>>>>>>>>>
> 
> What happens when App A uses one versioning scheme when posting 
> revisions to a repository, and App B uses a different versioning scheme
> when posting revisions to the same repository?   One app's post could
> violate the other app's semantics.

Are you referring to the Authorization-as-a-Service scenario? In that case, I expect the policies of different tenants to be completely separate. 
<<<
Agreed, but not the case of concern.

>>>
In the case of different applications of a single tenant, one could ask why there are multiple interfaces for maintaining shared policies in the first place?
<<<

Not multiple interfaces - Multiple applications using the same REST API interface to access shared policies. By the earlier suggestion, each application (client) is responsible for implementing versioning semantics, and the REST API server is just a holder of (mostly) opaque blobs.

If by "application" we mean a server based application that uses the REST API on the backend, well that's a somewhat controlled environment and can probably be managed into submission if two leviathan apps need to feed on the same policy repository.

However, if by "application" we mean Skippy's policy editor for Windows and George's policy editor for Mac, both running on the desktop and operating completely independently of each other against the same REST API repository operating on the same policies, then we have a much greater chance that these apps will not implement the same versioning semantics.  This scenario is less of a concern if the server enforces a particular versioning model.

I'm just concerned that leaving versioning semantics as an exercise for the client application developer will severely undermine interoperability - not because the client can't work with different implementations of the REST API, but because multiple clients working with the same REST API server on shared policies may interfere with each other's work if their respective versioning models are incompatible.

Since our hands are tied on the versioning semantic front (for now), maybe there's no way out of this at this point in time.

I also have a hunch that perhaps my concern is overblown, in the sense of how different could the versioning models of two apps be, given the environmental constraints laid out by the XACML core spec?  Child policies are contained within parent policies.  Parent policy behaviors are determined by their child policies. Modifying a child policy inherently modifies the parent policy's behavior as well, for every direct and indirect parent of the child policy all the way up to the root. 

Therefore, we could argue that any modification to a child policy must modify the version of the child policy and every policy in the parent chain, because not modifying the parent versions means you'd get different behaviors from the same "version" of the parent policy when child policies are modified.  This is true regardless of how the repository stores the policies internally. It's an artifact of the XACML containment model.

For XACML policy references, version propagation isn’t an issue. Modifying a referenced policy doesn't require bumping the version of the referees.

So if this is an implied consequence of the XACML policy containment model, perhaps it just isn't possible for two applications to implement versioning in dramatically different ways?

If there's consensus that this is the case, I'd be happy to declare my concern as 'moot'. :>

-Danny


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]