Is XACML the right name? #35
Comments
|
ALFA 2.0 can slot in beside JACL 1.0 and XACML 4.0. |
|
I would avoid anything with suffix "ACL" which may lead people to think this is a language for ACLs = Access Control Lists. (XACML is much more, this is ABAC!) |
|
If we swap "access control" (AC) with "authorization" (A) we get the easier to pronounce JAPL, XAPL and YAPL ("japple", "zapple" and "yapple") and of course the specification that ties them together is the APL Core 😄. |
|
JAzL, XAzL? AuthZ Language. Mixed cases, nice syllabic tempo. Rhymes with dazzle 😄 |
Yeah I thought of "APL" as well (as in Abac Policy Language or Authorization Policy Language works too) but then I stumbled upon an open source ABAC project called APL: https://github.com/intuit/identity-authz-apl But If you think that's no big deal, I'm fine with either APL or AzL (JAzL sounds cool for sure, but XAzL a bit hard to pronounce for me). |
|
Another suggestion to kick around: OASIS Authorization Policy Language (OAPL, sounds like OPAL), which leads to JOAPL (JOPAL) and YOAPL (YOPAL). The XML version is XACML 4.0. |
|
I think we should set up a vote online for TC members to vote on the proposals we have so far (I can do it with google forms for instance):
(I've just added the second one.) In all cases, we should keep the name "XACML" for the XML variant (at least in 4.0), that's why I don't mention it above, this is implicit. Let me know what you think. |
|
I just realized that I am going to have a hard time requesting Starter Documents for a specification that doesn't have a name...especially Core 😄 I was also thinking that since we are looking at the Core specification as being agnostic linguistically and applicably we might want to consider something more general for that and then introduce the "language" (XML, JSON) and "scope" (Access Control, etc.) into the Profile names. Perhaps something like SAR for Core (simple reference to the key elements) or SARC (SAR in Context)...? |
Indeed. What does SAR stand for? I assume we can fiddle the title in the text anytime, but we can't readily change the URLs and file name. A number of our candidate names revolve around "PL", for policy language. If we start with that then the URLs and filenames won't be that incongruous with whatever overarching name we finally settle on. I'm thinking something like:
I assume the first "xacml" in the URLs is determined by the TC name. "Concepts" would be a potential substitute for "Core". |
|
From the minutes:
Thinking further on what we discussed in the TC meeting, it's not really going to work for the long term with all documents in the same repository. We can manage it with the five successors to the core spec for a while but their life cycles will diverge. Especially in the later stages the XPath and JSONPath profiles won't need as many revisions but we're sort of locking ourselves into revving the draft number just because the core needs to. Add in the other profiles like RBAC, Hierarchy, SAML, etc., some of which might not need to revert to wd-01, and it gets messy. If each document is in its own repository then the problem goes away. The new TC rules let us treat committee specification drafts much like working drafts so we can rev the numbers more frequently without reviews and voting. This will be easier if each document is in its own repository. And we can still release working drafts for a document ahead of its first committee specification draft for interesting milestones. When we do increment a working draft or committee specification draft we could rename (i.e. renumber) the existing file or freeze the existing file (for historical reference) and create a copy with the new number. I'm thinking we freeze and copy and leave out the older versions when we package things up for TC Admin to publish. |
|
I agree the profiles will have different life cycles from the core, all the more as we make the core spec more format-agnostic, therefore less subject to evolutions of XML, JSON, YAML standards (and possibly new formats in the future like CBOR for instance); and therefore would be better managed with separate github repositories. Also if you need to review the history of changes to the core document only, or to a specific profile, it seems difficult if everything is merged to the As an example, OpenC2 TC (OASIS) seems to follow this approach (certain profiles have dedicated repositories). |
|
Yes, it really does make the CS look like a Working Draft. Challenging. Particularly from the consumption side. The OpenC2 repository makes a lot of sense in terms of managing updates for highly independent work artifacts. Assume that each of these was one of our Profiles (and XML, JSON and Core) and consider what the consumer friendly way to pull down all of the compatible versions into something that is a holistic spec would be? Technically, I don't think the fact that there are multiple document "components" in a repository is the issue. Consider an app releasing with multiple libraries, all being updated on different tempos. The overall release version is what allows consumers to know what the latest "prod" version is for the application. Keep in mind that historically there were periods where the Core Specification ran ahead of some of the Profiles so grabbing the "main" branch of each may not guarantee compatibility. I can envision version management becoming even more complex as we are basically creating a "forked" specification with XML and JSON (where, say, the XML and JSON RBAC Profiles are not in lockstep on revisions...or will we need to make that mandatory?) That said, I think the fact that Profiles are optional (outside of the new concept that at least one "language" Profile must be chosen) makes for a compelling case to keep Profiles separate at some level but, I am concerned that too much granularity will make consumption difficult. How about we consider 3 "structural" repositories: Core, XML and JSON, with the latter two containing all applicable "traditional" Profiles? We then internally develop a versioning model that spans all 3 repositories and that the main branch in each represents the latest "approved" version (merged from working branch once OK'd by TC)? The goal here is that if a consumer pulls (main) Core + XML or Core + JSON, that the resultant specification will be consistent across all included documents. Either that or it seems like we may need to provide either some sort of roadmap document that explains what combination of repository versions work together as a "Master Specification" or create and post a static file that the TC builds at each approved "milestone"...? P.S. All of this makes me wonder about calling the XML and JSON components "Profiles", given they are kinda "Co-Specs" on some level. P.P.S I think I am starting to overthink this, so stopping for a sanity check. 🤯 |
|
What does SAR stand for? Subject, Action, Resource. I was playing around with what it is, rather than what it does, given our discussion our potential forking... |
It looks like OpenC2 don't use use draft numbers in the file names in GitHub and only apply them when publishing a draft to the TC documents library. On the OASIS side it looks like business as usual. |
|
That makes sense. Using the names to store version information has been a construct that allows the traditional static library to act as a repository. Now that the docs are in an actual library it seems to me that the only version reference that is meaningful is that of the CS/Spec and that revisions be handled (opaquely to the Oasis library) in GitHub only. An issue that comes up there is that this means the only place to retrieve a CS/Spec is from the library, as git pulls will vary over time. On the plus side, business as usual has it’s advantages for consumers. |
We're intending to make it possible to implement the next version of XACML exclusively using JSON (so without touching XML at all). However, anyone seeing "XACML 4.0" is likely to assume that it is still based in XML and may not look any deeper. Should we be calling the next iteration something else?
What we call things is intertwined with how we separate the specification into multiple documents and how we present the JSON (Schema) versus XML (Schema) representations, which we give prominence and what is deemed optional. We should consider a potential rename first because it will drive those decisions.
Here are some thoughts in no particular order.
The X in XACML doesn't really stand for XML but kind of implies it, so we swap that out (JACML) or drop it and be agnostic (ACML). The "ML" (markup language) is also a bit of a throwback to the XML world so maybe we just shorten JACML to JACL.
A question arises over the version number. JACL 4.0 and ACML 4.0 are a bit strange without there being a preceding JACL 3 or ACML 3.
We could go with an overarching name (e.g., ACML 1.0) that has two representations known as JACL 1.0 and XACML 4.0, either of which could be an optional, separate profile. That solves the versioning question and indicates the continuity from XACML 3.0 to XACML 4.0.
We could name the representations relative to the overarching name, e.g., ACML-J 1.0, ACML-X 1.0 (a.k.a. XACML 4.0). Or ACML-JSON and ACML-XML.
ACML still has that "M" stuck in there, but ACL is a bit too nondescript. Perhaps we swap the X to E and drop the M: XACML -> EACL, perhaps with representations JEACL 1.0 and XACML 4.0.
The text was updated successfully, but these errors were encountered: