00:00:00:03 - 00:00:04:28 this presentation is really, to share my experiences 00:00:05:07 - 00:00:08:10 in implementing an OSCAL library. 00:00:08:11 - 00:00:11:11 I think there's a tremendous opportunity 00:00:11:12 - 00:00:15:11 for the OSCAL community outside of NIST to contribute 00:00:15:11 - 00:00:17:10 tooling is, of course, very important 00:00:17:10 - 00:00:20:06 because that’s at the end of the day what users are going to need. 00:00:20:07 - 00:00:22:25 But, to support that tooling to support 00:00:22:25 - 00:00:26:23 all of the other activities around compliance assessment, 00:00:26:24 - 00:00:29:20 and compliance documentation that OSCAL supports. 00:00:30:00 - 00:00:31:19 I think having really good, high quality 00:00:31:19 - 00:00:34:07 libraries is going to be a very helpful thing. 00:00:34:07 - 00:00:36:04 I've produced a library. 00:00:36:04 - 00:00:37:16 I'll let you make your own judgment 00:00:37:16 - 00:00:39:03 about whether you think it's a high quality or not. 00:00:39:06 - 00:00:40:07 I'd like to present, 00:00:40:09 - 00:00:43:21 a discussion of OSCAL from the perspective of someone, 00:00:43:23 - 00:00:46:16 implementing an OSCAL library. 00:00:46:24 - 00:00:49:05 Without further ado, I will get into the presentation. 00:00:49:22 - 00:00:50:22 what I'd like to start with. 00:00:50:22 - 00:00:53:04 And if this isn't going to be news for a lot of people on the call, 00:00:53:04 - 00:00:54:22 but just to frame the discussion, 00:00:55:04 - 00:00:58:06 I want to spend a couple of minutes distinguishing between 00:00:58:07 - 00:01:01:18 a user's perspective and a developer's perspective. 00:01:01:18 - 00:01:06:01 the experience in both cases is important, but it's it's different in some ways. 00:01:06:01 - 00:01:08:11 then I'd like to talk about what I see 00:01:08:11 - 00:01:11:26 as the purpose of an OSCAL API. 00:01:12:06 - 00:01:14:05 I'll present my library. 00:01:14:06 - 00:01:17:12 OSCAL-Pydantic not as the, end all be all, 00:01:17:20 - 00:01:20:04 but as a kind of worked example 00:01:20:04 - 00:01:21:14 of implementing OSCAL. 00:01:21:25 - 00:01:22:23 Python is, 00:01:22:24 - 00:01:25:12 can be implemented in an object oriented fashion, 00:01:25:12 - 00:01:26:27 and that's what I've chosen to do. 00:01:26:27 - 00:01:29:28 So, obviously there will be a lot of, 00:01:29:29 - 00:01:32:05 talk about inheritance and things like that. 00:01:32:15 - 00:01:34:19 and if you're not working in an object oriented programming 00:01:34:19 - 00:01:35:20 you'll still find some value. 00:01:35:20 - 00:01:39:01 and then of course, at the end I'll present some of the things 00:01:39:01 - 00:01:41:10 that I've found and some recommendations 00:01:41:10 - 00:01:43:25 I would have for, for me if I was starting over. 00:01:43:25 - 00:01:45:09 Without any further ado, 00:01:45:09 - 00:01:46:24 I'd like to get into it. 00:01:46:24 - 00:01:48:00 First, it's important 00:01:48:00 - 00:01:51:04 to distinguish between the view that a user takes, 00:01:51:04 - 00:01:55:07 or the view that a developer takes or UX versus DX. 00:01:55:19 - 00:01:59:04 User’s view and developer’s view are somewhat related. 00:01:59:11 - 00:02:01:29 The job of a good user experience is to create 00:02:01:29 - 00:02:05:23 a really pleasant experience for a non-technical person 00:02:05:23 - 00:02:09:26 who's trying to use some kind of tool to solve a business problem. 00:02:10:03 - 00:02:12:08 whereas a developer experience, 00:02:12:11 - 00:02:15:09 should still be pleasant, but it's really designed 00:02:15:09 - 00:02:19:05 for technical folks who are developing tools for users to use. 00:02:19:06 - 00:02:20:07 So in both cases, 00:02:20:07 - 00:02:23:08 the experience should be pleasant for each of those affected communities. 00:02:23:08 - 00:02:25:20 But there are some slight differences. 00:02:25:20 - 00:02:26:21 in short, 00:02:26:25 - 00:02:31:21 a good user experience allows the user to fight the problem that they're trying to solve. 00:02:31:21 - 00:02:33:29 Instead of fighting the interface. 00:02:33:29 - 00:02:35:29 Whereas, a good developer 00:02:35:29 - 00:02:39:04 API, good developer experience allows the user to fight 00:02:39:04 - 00:02:42:07 the problem they're trying to solve instead of fighting the API. 00:02:42:11 - 00:02:44:01 So, I have some 00:02:44:01 - 00:02:47:20 specific ideas and opinions about what makes a good API. 00:02:47:29 - 00:02:50:15 and you'll see those reflected in, in the work that I've done in 00:02:50:15 - 00:02:51:10 OSCAL-Pydantic 00:02:51:26 - 00:02:53:14 The features of a good API 00:02:53:14 - 00:02:54:07 first of all, in a good API, 00:02:54:07 - 00:02:55:16 first of all, in a good API, 00:02:55:18 - 00:02:58:19 it should be easy to do the most common things. 00:02:58:19 - 00:03:02:28 So whatever you're going to do, the the most of should be easy to accomplish. 00:03:03:01 - 00:03:04:00 and secondly, every, every API has kind of 00:03:04:00 - 00:03:05:03 and secondly, every API has kind of 00:03:05:03 - 00:03:08:16 a workflow built into it or an implicit set of assumptions about a process. 00:03:08:26 - 00:03:12:07 So if a user, if a developer, wants to accomplish a task, 00:03:12:07 - 00:03:17:01 the API should provide, an easy way to accomplish the task 00:03:17:01 - 00:03:21:10 that isn't going to create problems for the developer later on. 00:03:21:17 - 00:03:23:22 The API should be idiomatic. 00:03:23:22 - 00:03:27:25 And by that I mean that, we're dealing with external data. 00:03:27:25 - 00:03:29:19 We're dealing with OSCAL 00:03:29:19 - 00:03:33:09 but when it's presented to the programmer, the programmer should be seeing, 00:03:33:09 - 00:03:36:06 in my case, Python, in other cases 00:03:36:06 - 00:03:38:26 Java or Go or whatever. 00:03:38:26 - 00:03:42:00 the developer, bring some knowledge of their language. 00:03:42:05 - 00:03:43:14 They shouldn't have to learn 00:03:43:14 - 00:03:46:16 something radically different in order to make use of the library. 00:03:46:16 - 00:03:49:08 whatever is exposed by the API should be in line 00:03:49:08 - 00:03:52:15 with the expectations of the of the community around the language. 00:03:52:26 - 00:03:54:17 features should be discoverable. 00:03:54:17 - 00:03:58:12 So everyone starts an API trying to solve a specific problem. 00:03:58:12 - 00:03:59:18 They download it, right? 00:03:59:19 - 00:04:04:09 you should be able to kind of figure out the through documentation, but, 00:04:04:12 - 00:04:08:26 but the documentation is not a substitute for a well-designed, consistent API. 00:04:09:02 - 00:04:13:06 the developer should be able to figure out how to do what they want to do. 00:04:13:08 - 00:04:16:13 and an important part of that is that features need to be implemented 00:04:16:13 - 00:04:17:06 consistently. 00:04:17:06 - 00:04:21:01 So, if you figure out how to do one task in an API, 00:04:21:03 - 00:04:22:06 shouldn’t require 00:04:22:06 - 00:04:24:03 adopting a different conceptual model. 00:04:24:03 - 00:04:28:07 so consistency, documentation and presenting things in an idiomatic way, 00:04:28:10 - 00:04:32:10 will make it easy for, programmer to apply their language, 00:04:32:12 - 00:04:35:24 to a specific domain problem if the API's well constructed. 00:04:36:01 - 00:04:37:08 So, those are my opinions. 00:04:37:08 - 00:04:41:00 I hope they're not too controversial, but that was those were my objectives. 00:04:41:00 - 00:04:41:01 in designing our scale pedantic, 00:04:41:01 - 00:04:43:23 in designing OSCAL-Pydantic 00:04:43:28 - 00:04:47:20 I wanted the API to tick all of those boxes. 00:04:47:20 - 00:04:49:23 Oh, of course, one other, one other important point. 00:04:49:26 - 00:04:52:10 do as much of the typing for the programmer as you can, right. 00:04:52:10 - 00:04:55:24 Don't make some type of lot because then you make mistakes. 00:04:55:25 - 00:04:57:04 If you can save them some keystrokes, 00:04:57:10 - 00:04:57:29 do so. 00:04:58:02 - 00:04:59:02 The next question, 00:04:59:02 - 00:05:01:28 is essentially what is the purpose of an OSCAL API? 00:05:01:28 - 00:05:03:03 What is it for? 00:05:03:03 - 00:05:05:23 Most importantly, we want to reduce 00:05:05:23 - 00:05:09:12 the cognitive burden for, an OSCAL developer. 00:05:09:12 - 00:05:11:29 specifically around keeping OSCAL models in their head. 00:05:12:02 - 00:05:12:13 Right. 00:05:12:13 - 00:05:16:15 They shouldn't have to have the whole specification loaded in cache. 00:05:16:24 - 00:05:17:23 I don't know about you guys, 00:05:17:23 - 00:05:20:21 but I don't have a lot of cache in my brain, so I need, 00:05:20:21 - 00:05:22:22 I need to outsource that as much as possible. 00:05:22:25 - 00:05:25:06 And I think that a library, 00:05:25:08 - 00:05:27:11 should just expose the relevant parts 00:05:27:11 - 00:05:31:00 and let the let the API developer work with those instead of, 00:05:31:08 - 00:05:35:04 you know, having to navigate a really complex set of requirements. 00:05:35:13 - 00:05:39:20 Obviously that means easily focusing on the part of the specification 00:05:39:20 - 00:05:42:24 that you need to have in order to solve the problem at hand. 00:05:42:25 - 00:05:45:05 You're trying to solve some specific problem, 00:05:45:05 - 00:05:47:11 in order to solve that specific problem. 00:05:47:11 - 00:05:50:01 Ideally, the API should should expose just the bits 00:05:50:01 - 00:05:51:10 that you need to solve that problem. 00:05:51:17 - 00:05:52:23 Very important, 00:05:52:23 - 00:05:56:19 And, a common issue that we'll talk about in a couple of slides. 00:05:56:28 - 00:05:59:22 It's important for an API to produce OSCAL 00:05:59:22 - 00:06:02:22 data that is valid and well-formed. 00:06:02:27 - 00:06:06:17 So if your OSCAL API exports 00:06:06:17 - 00:06:08:19 OSCAL in XML, Java 00:06:08:19 - 00:06:09:24 or Yaml, 00:06:09:24 - 00:06:11:02 excuse me, Json or Yaml, 00:06:11:06 - 00:06:12:11 that data 00:06:12:12 - 00:06:13:06 should be fully compliant with the specification. 00:06:13:06 - 00:06:14:26 should be fully compliant with the specification. 00:06:15:00 - 00:06:16:12 it's an unfortunate situation 00:06:16:12 - 00:06:19:24 that I've encountered where some of the APIs will produce data. 00:06:19:24 - 00:06:20:27 That is not correct, 00:06:20:27 - 00:06:24:20 and I didn't realize it until I invested a lot of development cycles. 00:06:24:20 - 00:06:26:10 And then I had to go rebuild a bunch of stuff. 00:06:26:10 - 00:06:29:10 So we don't want I don't want that to happen for our APIs, 00:06:29:10 - 00:06:30:20 for our developer community. 00:06:30:21 - 00:06:33:27 of course I alluded to this already, but when you import OSCAL, 00:06:33:29 - 00:06:38:09 it should be presented not, as, you know, a really an OSCAL structure, 00:06:38:15 - 00:06:42:29 but really as objects or classes or whatever that is, 00:06:42:29 - 00:06:46:24 relevant in the context of the language that the API is written in. 00:06:46:24 - 00:06:49:02 So presented idiomatically. 00:06:49:09 - 00:06:50:26 And, I'm not sure that this 00:06:50:26 - 00:06:54:00 is a requirement for everyone, but it's a strong requirement of mine. 00:06:54:00 - 00:06:56:19 and it was it was one of the primary requirements that led me 00:06:56:19 - 00:07:00:15 to develop my own API instead of using the one of the existing ones. 00:07:00:19 - 00:07:03:05 I believe that people who want to solve 00:07:03:05 - 00:07:06:05 use cases leveraging the OSCAL standard 00:07:06:10 - 00:07:10:14 that are not specifically centered around 800-53, and that process 00:07:10:19 - 00:07:13:26 should be able to do so without impacting, 00:07:14:01 - 00:07:17:01 compatibility across other toolchains. 00:07:17:09 - 00:07:19:24 So, how to do that is a different challenge. 00:07:19:24 - 00:07:22:08 But I believe that that is an important goal, 00:07:22:08 - 00:07:22:24 mostly because 00:07:22:24 - 00:07:26:07 it was a very important goal for me, because I am trying to apply OSCAL 00:07:26:18 - 00:07:29:10 in a non 800-53 context. 00:07:29:12 - 00:07:31:16 So, one of the things I'd like to talk about 00:07:31:16 - 00:07:35:10 is the pros and cons of machine generated code. 00:07:35:22 - 00:07:38:04 so there are the specifications OSCAL 00:07:38:06 - 00:07:41:19 schemas have been released in a few different, flavors. 00:07:41:25 - 00:07:44:14 and there are some tools that will allow you to import the flavors 00:07:44:14 - 00:07:47:05 and automatically produce OSCAL, 00:07:47:06 - 00:07:50:15 objects that in a variety of languages, several of them are available. 00:07:50:22 - 00:07:55:02 I'm not necessarily, you know, trying to bag on any of them. 00:07:55:05 - 00:07:56:28 they meet a very specific purpose, 00:07:56:28 - 00:07:59:23 and they're very effective at doing a certain thing. 00:07:59:23 - 00:08:03:16 But it's very important to understand, in my opinion, the pros and cons, 00:08:03:20 - 00:08:06:26 So obviously from the perspective of, machine 00:08:06:26 - 00:08:08:23 generated code, it does some things very well. 00:08:08:27 - 00:08:10:20 It implements the full specification. 00:08:10:23 - 00:08:14:09 The full specification is encoded in whatever, whatever format you import. 00:08:14:15 - 00:08:16:18 It will just turn it all into, 00:08:16:18 - 00:08:19:09 the appropriate language constructs 00:08:19:09 - 00:08:20:29 because it's a process. 00:08:20:29 - 00:08:25:00 Once you implement the import process, you can run it as many times as you want. 00:08:25:08 - 00:08:26:22 you can always maintain an implementation. 00:08:26:22 - 00:08:30:06 It's up to date as new versions of OSCAL are released, 00:08:30:22 - 00:08:33:09 your implementation contracted very closely. 00:08:33:09 - 00:08:36:02 And of course, the other benefit is that you can have 00:08:36:02 - 00:08:39:17 multiple versions of the specifications supported by different APIs 00:08:39:17 - 00:08:44:03 or different flavors of the API because, some people need to migrate. 00:08:44:03 - 00:08:47:00 Handwritten code in these areas is not as great. 00:08:47:10 - 00:08:50:12 it implements as much as the specification as the author needs. 00:08:50:12 - 00:08:51:29 So while, 00:08:52:00 - 00:08:54:18 OSCAL-Pydantic is great, 00:08:54:19 - 00:08:58:11 at implementing the artifacts required for a good quality catalog, 00:08:58:22 - 00:09:05:03 for example, we've rudimentary support for profiles and SSPs and, 00:09:05:03 - 00:09:08:11 not all those other artifacts are just, just not implemented yet. 00:09:08:18 - 00:09:10:24 the primary reason is that I needed catalogs 00:09:10:24 - 00:09:13:24 and I needed a really high quality representation of a catalog. 00:09:14:01 - 00:09:15:19 So that's what I developed. 00:09:15:19 - 00:09:19:21 And over time, of course, other other parts of the specification 00:09:19:21 - 00:09:20:12 will be implemented. 00:09:20:12 - 00:09:22:28 But because I because I'm doing it all by hand, 00:09:22:28 - 00:09:25:24 I have to write it all or convince somebody to help me write it all. 00:09:25:24 - 00:09:27:06 So, that's one downside. 00:09:27:10 - 00:09:30:24 It will be updated, whenever someone feels like updating it. 00:09:30:24 - 00:09:32:27 Right. So so it's not automatic. 00:09:32:27 - 00:09:35:04 You can't just run the tool against the new version. 00:09:35:04 - 00:09:37:22 You have to you have to manually go in and figure out what the differences are 00:09:37:22 - 00:09:39:00 and implement those. 00:09:39:00 - 00:09:41:17 Obviously I only needed the latest version. 00:09:41:17 - 00:09:44:28 So that's the latest version of the OSCAL specification. 00:09:44:28 - 00:09:47:02 That's the version OSCAL-Pydantic supports 00:09:47:07 - 00:09:51:11 You can't necessarily import data from an older version. 00:09:51:11 - 00:09:53:02 and get the same result. Right. So 00:09:53:15 - 00:09:54:24 however, I will say that 00:09:54:24 - 00:09:58:11 there are definitely some downsides to machine generated code. 00:09:58:20 - 00:10:01:27 for me, extensibility, being able to apply OSCAL 00:10:01:27 - 00:10:06:15 outside of the 800-53 context was, a key objective 00:10:06:20 - 00:10:08:26 and, machine generated code 00:10:08:26 - 00:10:11:03 treats the specification as a closed loop, right? 00:10:11:03 - 00:10:14:00 So you get a really good representation, but it's, it's a closed loop. 00:10:14:00 - 00:10:16:25 It's really not designed necessarily to be extensible 00:10:16:25 - 00:10:20:08 in many of the tools that I've seen for automatically generating code, 00:10:20:16 - 00:10:23:04 it's also limited by the quality of the inputs. 00:10:23:04 - 00:10:25:00 So one of the big challenges 00:10:25:00 - 00:10:28:23 with the Json OSCAL specification is it's just not complete. 00:10:28:23 - 00:10:32:13 It doesn't include all of the, restrictions, 00:10:32:17 - 00:10:34:28 that are present in the meta schema version. 00:10:34:28 - 00:10:37:08 The meta schema is the authoritative version. 00:10:37:08 - 00:10:41:22 Json schema is a translation of that that drops some stuff, because Json 00:10:41:29 - 00:10:46:03 schema just can't express everything that Meta-Schema mechanically can express. 00:10:46:03 - 00:10:49:18 And so as a result, you're automatically generated code will allow you 00:10:49:18 - 00:10:52:13 to produce OSCAL that isn't compliant with the standard. 00:10:52:16 - 00:10:53:12 And finally, 00:10:53:12 - 00:10:56:26 and this is really implementation specific, but this these tools 00:10:56:26 - 00:11:01:00 are generally designed to allow you to quickly import something. 00:11:01:00 - 00:11:05:03 And the expectation is not necessarily that the code that you produce 00:11:05:03 - 00:11:08:13 is going to be your authoritative representation, because your authoritative 00:11:08:13 - 00:11:11:20 representation is, is some external Json schema or something like that. 00:11:11:20 - 00:11:12:10 Right? 00:11:12:10 - 00:11:16:23 As a side effect, it doesn't need to produce, you know, very pretty code. 00:11:17:01 - 00:11:20:06 whereas if you need something that a developer is going to extend, 00:11:20:06 - 00:11:22:13 you need to really think about what the developer is going to see 00:11:22:13 - 00:11:25:03 and whether it's beautiful and nice to look at. 00:11:25:03 - 00:11:29:11 So, in my experience, some of that code can be very verbose, 00:11:29:11 - 00:11:33:16 a lot of repetition, very difficult to understand and make sense of. 00:11:33:29 - 00:11:36:16 This is where handwritten code can shine. 00:11:36:16 - 00:11:39:23 obviously, because you're a you're a human with an objective in mind, 00:11:40:00 - 00:11:42:28 you can design it for extensibility out of the gate. 00:11:42:28 - 00:11:45:24 it is not dependent on the limitations of the structure. 00:11:45:24 - 00:11:50:08 So for example, I used the website a lot as a reference. 00:11:50:17 - 00:11:54:17 Obviously the website can't be directly translated into code, and sometimes 00:11:54:17 - 00:11:58:04 I needed to go look at the meta schema to really understand how something works. 00:11:58:20 - 00:12:01:10 But I can do that because I'm a human being 00:12:01:10 - 00:12:04:10 so I can apply my brain to this problem. 00:12:04:10 - 00:12:05:11 you know, automatic code 00:12:05:11 - 00:12:08:11 generators just go through this, go on the basis of what you feed them. 00:12:08:18 - 00:12:11:15 and of course, I've really tried to make readability, 00:12:11:23 - 00:12:14:09 a central feature of, of my implementation. 00:12:14:09 - 00:12:18:07 So, I'm not saying that machine generated code is bad. 00:12:18:07 - 00:12:21:29 I think there are a lot of, places where it can really make sense, 00:12:21:29 - 00:12:24:26 particularly if your scope is kind of limited to, 00:12:24:26 - 00:12:25:26 maybe taking existing tool 00:12:25:26 - 00:12:30:05 that's written in, in an existing language and, adding on OSCAL 00:12:30:05 - 00:12:33:05 compatibility as a, as an external format or something like that 00:12:33:08 - 00:12:35:02 can really be a time saver. 00:12:35:02 - 00:12:36:23 But it does come with limitations. 00:12:36:23 - 00:12:40:06 So if you are writing a library, you might want to think about 00:12:40:08 - 00:12:41:21 trying to do it by hand first. 00:12:42:08 - 00:12:43:03 With that I would like 00:12:43:03 - 00:12:47:17 to talk about OSCAL-Pydantic again not the end all and be all. 00:12:47:17 - 00:12:48:18 It has some limitations. 00:12:48:18 - 00:12:51:10 Some I have talked about, some I haven't talked about, many 00:12:51:10 - 00:12:53:13 I won't get to because there just won't be time. 00:12:53:13 - 00:12:55:11 But it's a kind of a worked example. 00:12:55:11 - 00:12:59:28 So it reflects all of my opinions and biases that I, that I've discussed 00:12:59:28 - 00:13:01:13 so far in the presentation. 00:13:01:13 - 00:13:07:00 but I think it has a reasonably well considered model 00:13:07:07 - 00:13:10:15 for taking the OSCAL standard or really 00:13:10:15 - 00:13:12:27 any standard expressed in meta schema and, 00:13:12:29 - 00:13:15:29 producing code that is extensible 00:13:15:29 - 00:13:20:10 and complete, accurate and I think fun to work with. 00:13:21:07 - 00:13:22:05 a quick introduction 00:13:22:05 - 00:13:26:03 if this is your first time hearing about OSCAL-Pydantic it's, it's a library. 00:13:26:06 - 00:13:28:16 It's written in Python and very much pythonic. 00:13:28:16 - 00:13:31:13 It's really designed to feel like Python. 00:13:31:13 - 00:13:33:29 It uses type hinting very extensively because I think that's really cool 00:13:34:01 - 00:13:37:16 And so, obviously it leverages the Pydantic, 00:13:37:23 - 00:13:40:10 library, because that can, that can, you know, enforce 00:13:40:10 - 00:13:42:08 type restrictions and some other stuff that isn't, isn't built 00:13:42:08 - 00:13:43:06 into the base of Python. 00:13:43:27 - 00:13:46:11 Also really, really good at bringing in Json or producing Json. 00:13:46:11 - 00:13:48:20 So that's helpful. 00:13:48:24 - 00:13:51:04 It implement something that looks a little bit like data classes. 00:13:51:04 - 00:13:54:29 So data classes are not unique to Python, but I think generally unique 00:13:54:29 - 00:13:56:24 to object oriented languages. 00:13:56:24 - 00:13:58:29 But if you know what data classes are, that's helpful. 00:13:58:29 - 00:14:00:29 And if you don't, I guess it's probably not helpful. 00:14:00:29 - 00:14:03:02 But it implements something that looks like data classes 00:14:03:20 - 00:14:06:26 and leverages the pedantic, APIs already said 00:14:07:03 - 00:14:08:13 it is handwritten, 00:14:08:13 - 00:14:11:14 in order to optimize the developer experience 00:14:11:19 - 00:14:15:15 for encoding OSCAL, and also for extending OSCAL. 00:14:15:23 - 00:14:17:14 so, the way that 00:14:17:14 - 00:14:20:20 OSCAL-Pydantic is structured, this would be, you know, 00:14:20:23 - 00:14:24:00 very familiar to anybody who's worked with object oriented languages. 00:14:24:09 - 00:14:26:13 But there is, something called a model 00:14:26:13 - 00:14:30:08 that is the basis for the entire, library. 00:14:30:11 - 00:14:32:25 it is extended, by subclasses 00:14:32:29 - 00:14:35:29 and then sometimes some extended by some subclasses. 00:14:36:00 - 00:14:37:02 the way that the 00:14:37:08 - 00:14:41:18 structure works and the way it is that's laid out is that the OSCAL model 00:14:41:24 - 00:14:44:02 really encapsulates behavior. 00:14:44:02 - 00:14:46:03 It's not, it's not about data. 00:14:46:03 - 00:14:48:16 It's about, functions for transforming data 00:14:48:16 - 00:14:51:27 that are useful for almost every subclass. 00:14:52:02 - 00:14:53:11 And certain things 00:14:53:11 - 00:14:56:11 like Json encoding and some other things I'll talk about later. 00:14:56:12 - 00:14:57:16 then there's another layer, 00:14:57:16 - 00:15:02:05 are the classes that immediately subclass OSCAL model are usually structural. 00:15:02:11 - 00:15:06:01 So they define what a certain kind of OSCAL 00:15:06:01 - 00:15:10:06 assembly or something looks like what are the attributes that are relevant? 00:15:10:08 - 00:15:13:09 and then because there are several types of OSCAL 00:15:13:09 - 00:15:16:01 assemblies where the contents 00:15:16:02 - 00:15:19:01 and the restrictions on the contents depend on where they, 00:15:19:01 - 00:15:22:24 where they sit inside and OSCAL document of some sort. 00:15:22:24 - 00:15:23:27 the third layer 00:15:23:27 - 00:15:27:28 is really about imposing constraints on the structure. 00:15:28:01 - 00:15:30:10 So, for example we have a properties. 00:15:30:10 - 00:15:33:18 is a big point of extension within OSCAL. 00:15:33:18 - 00:15:37:05 We have a base property that defines a structure for a property. 00:15:37:14 - 00:15:40:18 And then we have a kind of flavors of properties that are subclasses 00:15:40:18 - 00:15:42:05 that impose various constraints. 00:15:42:05 - 00:15:44:11 And we'll talk about what those constraints are. 00:15:44:11 - 00:15:45:28 And What they're intended to do. 00:15:46:03 - 00:15:49:04 There is one other important part which kind of doesn't really fit 00:15:49:04 - 00:15:52:17 in, but is very, very important foundational called data types. 00:15:52:28 - 00:15:56:20 The authoritative representation of the OSCAL standard 00:15:56:20 - 00:16:00:16 is in a language called meta schema, which you've probably all heard of. 00:16:00:16 - 00:16:02:06 It's an XML based language. 00:16:02:09 - 00:16:05:25 the data types in OSCAL are actually defined in meta schema. 00:16:06:04 - 00:16:08:17 As you can see, there's a long list of them. 00:16:08:17 - 00:16:11:10 they are essentially strings, 00:16:11:10 - 00:16:13:12 with regular expression code, 00:16:13:16 - 00:16:16:04 to ensure that they fit in a format because it's, you know, in 00:16:16:04 - 00:16:20:16 Json, XML and Yaml, you're dealing a lot with strings. 00:16:20:21 - 00:16:24:10 the function of the data types library is to take those strings 00:16:24:17 - 00:16:27:17 and ensure that they conform to the specification 00:16:27:23 - 00:16:32:04 and, if necessary, translate them into whatever Python would use. 00:16:32:04 - 00:16:34:16 So, for example, an OSCAL bool 00:16:34:17 - 00:16:37:19 can be the word true, but not in OSCAL 00:16:37:19 - 00:16:38:08 It'll be 00:16:38:09 - 00:16:40:04 true like boolean true, but not a string. 00:16:40:04 - 00:16:41:01 Right? 00:16:41:01 - 00:16:42:07 That's something that, 00:16:42:07 - 00:16:44:26 will be very distinct in each programing language. 00:16:44:26 - 00:16:48:06 And fortunately it is a pretty straightforward task, 00:16:48:13 - 00:16:51:15 but obviously there's a lot of fiddly data types, so you'll need 00:16:51:15 - 00:16:52:20 to you'll need to get through those, 00:16:52:20 - 00:16:56:14 so the next layer is the the base model, right. 00:16:56:14 - 00:17:01:02 The OSCAL model that encapsulates a bunch of shared behavior. 00:17:01:02 - 00:17:05:25 So, one thing it encapsulates is core validation logic. 00:17:05:25 - 00:17:08:05 We'll get into validation in a couple of slides, 00:17:08:05 - 00:17:12:05 but just be aware that the actual logic, that process of the validation 00:17:12:05 - 00:17:14:26 is all defined in that in that base class. 00:17:14:26 - 00:17:19:08 And then each of the subclasses just provides the information about the, 00:17:19:08 - 00:17:22:03 the permitted values or other restrictions that are relevant. 00:17:22:09 - 00:17:26:12 It also defined some basic behavior that's common to all the models. 00:17:26:12 - 00:17:29:09 So, I have some preferences about Json serialization. 00:17:29:09 - 00:17:32:20 there are some attribute values in the OSCAL specification 00:17:32:20 - 00:17:33:28 that are reserved keywords. 00:17:33:28 - 00:17:36:26 And a lot of object oriented languages like class. 00:17:36:27 - 00:17:40:14 So obviously we had to do something to make that word available. 00:17:40:14 - 00:17:43:20 and of course, the intent is that almost every object 00:17:43:20 - 00:17:47:05 in the library extends the OSCAL model directly. 00:17:47:05 - 00:17:51:15 And from a programmer's perspective, you probably don't need to worry 00:17:51:15 - 00:17:53:14 about the existence of OSCAL model at all. 00:17:53:16 - 00:17:55:29 The next layer down are structural models. 00:17:56:07 - 00:17:59:19 so now fortunately, we'll get into actual kind of code here. 00:17:59:22 - 00:18:01:21 in OSCAL they're called assemblies. 00:18:01:21 - 00:18:02:26 they are, 00:18:02:26 - 00:18:07:09 you know, bags of attributes, attributes that each have their own, types 00:18:07:09 - 00:18:10:10 which impose restrictions and sometimes additional restrictions. 00:18:10:15 - 00:18:14:08 A structural model really just defines the, 00:18:14:09 - 00:18:17:09 the very basic level of restrictions, 00:18:17:12 - 00:18:20:03 and identifies basic type information. 00:18:20:03 - 00:18:22:27 So type referring to the data types 00:18:22:27 - 00:18:25:29 that are part of the OSCAL standard or the metal schema standard. 00:18:26:00 - 00:18:27:03 Here's an example. 00:18:27:03 - 00:18:28:21 hopefully the font is not too small. 00:18:28:21 - 00:18:30:02 As I said, property 00:18:30:10 - 00:18:33:19 is one of the OSCAL entities 00:18:33:19 - 00:18:36:15 that is really key to, 00:18:36:15 - 00:18:39:06 extending OSCAL to meet other requirements. 00:18:39:17 - 00:18:42:17 There are a lot of different flavors of properties. 00:18:42:21 - 00:18:45:22 And so I spent a lot of time in property, 00:18:45:22 - 00:18:49:00 figuring out how to make it work effectively in a good way. 00:18:49:00 - 00:18:51:11 what you'll see here is the base property. 00:18:51:11 - 00:18:54:21 So again, not something you generally need to worry 00:18:54:21 - 00:18:56:19 about as a developer, but, a property will have 00:18:56:19 - 00:19:00:14 a name, it'll have a UUID, it'll have a name space, a value. 00:19:00:21 - 00:19:04:01 It'll have something that is called class in the specification. 00:19:04:01 - 00:19:07:27 But I call it prop class because class is a reserved word in most languages. 00:19:08:02 - 00:19:10:04 And there's a remarks field. 00:19:10:04 - 00:19:12:22 And you can see we'll talk about this a little bit later, 00:19:12:22 - 00:19:15:19 but there's some decoration in there, some type hinting to indicate 00:19:15:19 - 00:19:19:02 which of the values are, optional, which are mandatory. 00:19:19:02 - 00:19:20:20 and to try to make the 00:19:20:20 - 00:19:23:03 developers experience easier. 00:19:23:03 - 00:19:25:10 if a field is optional, it usually has a default 00:19:25:10 - 00:19:28:08 value of none or, you know, no value. 00:19:28:08 - 00:19:31:09 the Submodels will impose constraints. 00:19:31:23 - 00:19:34:07 So there are a variety of constraints. 00:19:34:09 - 00:19:37:27 It's important to note that those are typically, 00:19:37:28 - 00:19:41:20 presented most accurately in the meta schema language. 00:19:42:04 - 00:19:46:14 So if you really want to see what these things look like, go to meta schema. 00:19:46:14 - 00:19:50:00 And I think unfortunately they might be called something different in meta schema. 00:19:50:14 - 00:19:51:25 they might have different terms of meta schema. 00:19:52:06 - 00:19:54:19 so let's talk about cardinality constraints. 00:19:54:20 - 00:19:58:14 Cardinality constraint is how many times, an attribute should appear. 00:19:58:24 - 00:20:00:14 usually I think always. 00:20:00:14 - 00:20:01:25 But I wanted to hedge my bets. 00:20:01:25 - 00:20:03:09 It’s either a 0 or 1 00:20:03:09 - 00:20:05:18 So an attribute is optional. 00:20:05:18 - 00:20:07:15 one an attribute is mandatory. 00:20:07:15 - 00:20:09:19 or zero through infinity, 00:20:09:19 - 00:20:14:04 which is a way of collecting a list of attributes. 00:20:14:05 - 00:20:17:01 it could be an empty list or it could be a, like a large list. 00:20:17:01 - 00:20:20:23 So, that is how cardinality is expressed. 00:20:21:01 - 00:20:23:23 And in my code, again, it all looks like Python. 00:20:23:23 - 00:20:27:25 You'll see for a cardinality of one, we define a property. 00:20:27:28 - 00:20:30:01 and simply identify the type 00:20:30:07 - 00:20:31:24 It works the same way in data classes. 00:20:31:24 - 00:20:33:13 So you don't need to worry about Pydantic, but 00:20:33:14 - 00:20:36:01 if it's 0 or 1, again, that's a different type. 00:20:36:01 - 00:20:38:01 Hint it's either the object or a none. 00:20:38:01 - 00:20:39:17 No one is like null, right? 00:20:39:17 - 00:20:42:03 and then if the cardinality is zero 00:20:42:03 - 00:20:45:07 or infinite, it's an optional list. 00:20:45:15 - 00:20:48:23 So it'll be a list of data types or nothing. 00:20:49:02 - 00:20:50:00 the next 00:20:50:00 - 00:20:52:15 common constraint will be a value constraint. 00:20:52:15 - 00:20:53:25 you've got attributes, 00:20:53:28 - 00:20:56:01 Each of those attributes can have sets of values. 00:20:56:01 - 00:20:59:12 sometimes you have to restrict a set of values that are allowed 00:20:59:12 - 00:21:02:29 in a certain object, in a certain place in a OSCAL schema. 00:21:02:29 - 00:21:05:29 So, you can express them as either 00:21:06:00 - 00:21:08:25 a value or a set of values. 00:21:08:25 - 00:21:11:07 So it could be a set of properties that 00:21:11:07 - 00:21:14:15 if one of them is, is one, the other has to be some other thing. 00:21:14:16 - 00:21:15:08 Right. 00:21:15:10 - 00:21:17:28 and you can express multiple constraints, because sometimes 00:21:17:28 - 00:21:20:20 they're different sets of properties that are available to an object. 00:21:20:20 - 00:21:22:14 within a constraint, 00:21:22:14 - 00:21:24:03 you basically have to AND 00:21:24:03 - 00:21:26:09 and then between constraints, 00:21:26:09 - 00:21:27:12 you can OR 00:21:27:12 - 00:21:29:14 in the meta schema specification, 00:21:29:14 - 00:21:31:14 look out for something that says in on the website, 00:21:31:14 - 00:21:35:13 it it says may be locally defined, but in the meta schema 00:21:35:13 - 00:21:39:01 specification itself you'll see allow other equals. Yes. 00:21:39:16 - 00:21:41:20 What that basically means is that there's 00:21:41:20 - 00:21:46:14 a recommended set of restrictions but that other values are allowed. 00:21:47:01 - 00:21:49:04 So this is a little tough for me. 00:21:49:04 - 00:21:52:23 and I just ignored it because it's not compliant 00:21:52:23 - 00:21:57:10 with the specification, but I just didn't like the idea of an optional restriction. 00:21:57:15 - 00:21:57:22 Right. 00:21:57:22 - 00:22:00:04 It's either a restriction or it's not a restriction. 00:22:00:04 - 00:22:03:11 So I ignored the allowed or allow other. Yes. 00:22:03:11 - 00:22:05:13 With with one exception. 00:22:05:13 - 00:22:09:16 and then I made sure that it was trivial to extend OSCAL. 00:22:09:16 - 00:22:14:11 So if you need to have your own property, you can always create a new subclass, 00:22:14:13 - 00:22:17:22 extend OSCAL properties to have whatever you want. 00:22:18:00 - 00:22:19:04 But you have to do that. 00:22:19:04 - 00:22:21:02 And it's not like you're going to have a restricted thing. 00:22:21:02 - 00:22:22:25 But oh, by the way, put whatever you want in there. So, 00:22:22:26 - 00:22:26:11 here is an example of a property and a set of restrictions. 00:22:26:14 - 00:22:29:22 so you'll see, this again is not meta schema. 00:22:29:22 - 00:22:32:02 This is not Json schema, this is Python. 00:22:32:05 - 00:22:35:10 if a name field in the property has a value of type, 00:22:35:14 - 00:22:40:11 then the value of the property can be one of a long list of things. 00:22:40:20 - 00:22:42:01 so that's an OR 00:22:42:01 - 00:22:43:22 Any of those values are appropriate. 00:22:43:23 - 00:22:44:17 However, 00:22:44:18 - 00:22:46:25 any of those values are appropriate only if 00:22:46:25 - 00:22:49:10 the name property has a value of type 00:22:49:13 - 00:22:51:17 So in that case it's an AND. Right. 00:22:51:17 - 00:22:54:18 And so my logic in my core processor reflects that. 00:22:54:24 - 00:22:56:14 but wait, there's more. 00:22:56:14 - 00:22:58:24 Because, you will see that, 00:22:58:24 - 00:23:03:17 version is also a perfectly valid value for the name property 00:23:03:24 - 00:23:07:15 of a resource in this particular location in OSCAL document. 00:23:08:05 - 00:23:11:05 But if it's type there are a lot of other restrictions. 00:23:11:09 - 00:23:13:28 So you'll see this encoded in 00:23:13:28 - 00:23:15:29 in the OSCAL specification in meta schema. 00:23:16:10 - 00:23:19:27 another thing that I actually just invented. 00:23:20:03 - 00:23:23:03 I invented type applied in the OSCAL context. 00:23:23:09 - 00:23:25:12 To a meta schema specification. 00:23:25:12 - 00:23:26:20 they don't exist in meta schema. 00:23:26:20 - 00:23:30:06 Meta schema has assemblies, but they don't really have, types in the way 00:23:30:06 - 00:23:34:19 that I use them, which is for flavors of a property. 00:23:34:21 - 00:23:36:25 Property is the big one because there is a property that has a 00:23:36:25 - 00:23:38:12 it has a specification of 00:23:38:12 - 00:23:39:12 fields and values. 00:23:39:12 - 00:23:41:13 But there are a lot of variation 00:23:41:20 - 00:23:45:05 and the variation depends on where in a document it appears. 00:23:45:05 - 00:23:47:18 So it was really just screaming 00:23:47:18 - 00:23:49:15 for lots and lots of subclassing. 00:23:49:15 - 00:23:50:14 So that's what I did. 00:23:50:25 - 00:23:52:11 so, every time 00:23:52:11 - 00:23:55:11 there's, value constraint, that's a new subclass. 00:23:55:16 - 00:23:57:11 inside the larger objects 00:23:57:11 - 00:24:02:16 that incorporate properties or other types of OSCAL objects, 00:24:02:17 - 00:24:05:12 you can define which of the types, 00:24:05:12 - 00:24:06:07 are allowed. 00:24:06:07 - 00:24:07:18 here you'll see, I have, 00:24:07:19 - 00:24:08:08 data structure. 00:24:08:08 - 00:24:11:19 It's a dictionary of a list of dictionaries, called allowed field types. 00:24:12:06 - 00:24:14:19 And it specifies that in the props 00:24:14:20 - 00:24:15:11 field 00:24:15:11 - 00:24:18:04 the props field will contain an object, 00:24:18:04 - 00:24:21:12 it'll conform to the base property specification, right? 00:24:21:12 - 00:24:24:16 It'll have a name, a UUID namespace, a value, all those other things. 00:24:24:29 - 00:24:29:25 But the permitted values will be further constrained 00:24:30:00 - 00:24:33:00 and must comply with one of these three flavors. 00:24:33:05 - 00:24:36:12 So that logic again is implemented in the base class. 00:24:36:20 - 00:24:40:04 there is deprecation constraint in some cases 00:24:40:06 - 00:24:41:14 in the OSCAL specification, 00:24:41:23 - 00:24:45:01 you'll see a value that's technically legal but deprecated. 00:24:45:01 - 00:24:45:02 you'll see a value that's technically legal but deprecated. 00:24:45:02 - 00:24:46:21 great example, in 00:24:46:21 - 00:24:50:18 the property that you can associate with an OSCAL control. 00:24:50:23 - 00:24:53:11 Again, it's a, it's a different flavor of property. 00:24:53:11 - 00:24:55:28 you may have a value of withdrawn. 00:24:56:04 - 00:24:57:14 But withdrawn can be 00:24:57:14 - 00:24:59:15 capitalized or not capitalized. 00:24:59:21 - 00:25:02:06 The capitalized version of the string is deprecated. 00:25:02:21 - 00:25:04:18 So we allow it. 00:25:04:18 - 00:25:05:22 But we raise a warning 00:25:05:22 - 00:25:07:10 if the value of the property 00:25:07:15 - 00:25:08:27 in the control 00:25:08:27 - 00:25:12:11 contains a value of warning, but the warning is capitalized. 00:25:13:02 - 00:25:13:22 It's permitted. 00:25:13:22 - 00:25:15:15 But we're going to we're going to throw a warning to console. 00:25:15:15 - 00:25:17:12 So if you're watching the console you'll see a warning. 00:25:17:12 - 00:25:21:18 And you'll hopefully realize that you need to make that the lowercase version. So 00:25:21:18 - 00:25:24:16 In some cases there are uniqueness constraint. 00:25:24:16 - 00:25:25:27 you might need to prevent, 00:25:26:01 - 00:25:29:13 values, property values from being duplicates. 00:25:29:17 - 00:25:31:18 the place where you'll see this 00:25:31:18 - 00:25:35:14 most readily, most importantly is, in a resource. 00:25:35:22 - 00:25:38:20 So if you know the OSCAL specification, 00:25:38:20 - 00:25:41:25 you'll know that at the end there's a section called back matter. 00:25:42:03 - 00:25:45:19 Back matter contains a bunch of resources 00:25:46:01 - 00:25:47:29 which, again, have their own structure. 00:25:48:03 - 00:25:52:06 one of the things that they can have in it is a link, which is intended 00:25:52:06 - 00:25:56:01 to point to either a location inside the document 00:25:56:10 - 00:25:58:20 or, an external URL. 00:25:58:24 - 00:26:02:00 So the only rule is, you can't have two resources 00:26:02:00 - 00:26:06:02 that point to the same place because, the intention is that you're going to have 00:26:06:05 - 00:26:07:24 you're going to have a format for them. 00:26:08:01 - 00:26:10:14 you can optionally have, you know, some hash 00:26:10:14 - 00:26:13:23 or checksum, to make sure it's an authentic copy. 00:26:13:27 - 00:26:18:29 So as a result, each resource can have as many URLs that you want, 00:26:19:09 - 00:26:21:21 but, each URL has to be unique. 00:26:21:21 - 00:26:24:07 you know, more than one resource can't have the same URL. 00:26:24:07 - 00:26:26:15 Or, in this case, a URL 00:26:26:15 - 00:26:29:01 cannot appear more than once in a resource. 00:26:29:01 - 00:26:31:18 basically we're, we're counting the links. 00:26:31:21 - 00:26:33:19 And if and then passing that to a function that will say, 00:26:33:26 - 00:26:36:13 I saw this one time, I saw this five times I saw this. 00:26:36:13 - 00:26:37:16 How many times? 00:26:37:16 - 00:26:40:16 And if any of those numbers are bigger than one, then we throw an error. So, 00:26:41:01 - 00:26:43:18 There are in some cases very special constraints. 00:26:43:18 - 00:26:46:10 So some objects, my favorite is hash. 00:26:46:10 - 00:26:47:23 have their own 00:26:47:23 - 00:26:50:22 constraints that don't really apply to other objects. 00:26:50:22 - 00:26:53:25 And this is the only case, I think, in my code 00:26:53:25 - 00:26:56:19 base where I allowed allow others. 00:26:56:21 - 00:26:58:18 So the constraint constraint is expressed 00:26:58:18 - 00:26:59:10 like this. 00:26:59:11 - 00:27:03:02 you have in a hash an algorithm and a value. 00:27:03:13 - 00:27:04:11 The algorithm 00:27:04:13 - 00:27:07:28 obviously tells you what algorithm was used to calculate the value. 00:27:08:03 - 00:27:10:18 and as a result, the value 00:27:10:25 - 00:27:15:00 should be something that would be produced by that algorithm. 00:27:15:10 - 00:27:17:15 Obviously there are a number of algorithms. 00:27:17:22 - 00:27:20:00 in the meta schema specification, 00:27:20:00 - 00:27:23:20 this, by the way, does not appear in the Json schema. 00:27:23:20 - 00:27:25:16 So this is one of the things you're missing out on. 00:27:25:16 - 00:27:29:10 If you're if you're just leveraging Json schema, if the algorithm is 00:27:29:10 - 00:27:34:01 this thing, then it's going to be 28 characters of hex, essentially. 00:27:34:07 - 00:27:36:24 otherwise it'll be 32 or 48 or 64, right. 00:27:37:07 - 00:27:38:20 And so I implemented it. 00:27:38:20 - 00:27:40:29 I'm only showing you part of the implementation, but 00:27:40:29 - 00:27:43:19 if the algorithm string is 00:27:43:19 - 00:27:47:00 SCHA 224 or SCHA 3224, 00:27:47:09 - 00:27:50:15 if the length of the value is 28 characters 00:27:50:15 - 00:27:54:26 and it's hex expressible as hex, then it's okay. 00:27:54:26 - 00:27:56:23 Otherwise throw an error. 00:27:56:23 - 00:27:58:19 So that's a constraint. 00:27:58:19 - 00:28:00:04 it's not a general constraint. 00:28:00:04 - 00:28:01:03 There aren't a lot of, 00:28:01:06 - 00:28:03:15 parts of OSCAL that share that constraint. 00:28:03:15 - 00:28:05:00 So it's kind of a special one. 00:28:05:03 - 00:28:10:01 and in those cases, I need the decision to put it in the object itself 00:28:10:01 - 00:28:11:06 all the way down the subclass 00:28:11:06 - 00:28:14:06 rather than including it in one of the higher level classes. 00:28:14:08 - 00:28:17:14 you may make a different decision for, for great reasons. 00:28:17:29 - 00:28:22:16 So, that was a really high level tour of my library. 00:28:22:23 - 00:28:25:29 And my intention was not really to present the library. 00:28:25:29 - 00:28:28:17 Obviously, I went through it in two quick and at too high a level 00:28:28:17 - 00:28:31:00 for anyone to go use it for anything. 00:28:31:00 - 00:28:31:12 But, 00:28:31:12 - 00:28:34:24 really to explain how I took the different elements of the OSCAL 00:28:34:24 - 00:28:37:27 specification and applied them in 00:28:37:27 - 00:28:43:00 Python context to make Python essentially data classes. 00:28:43:04 - 00:28:46:04 I learned many things from the exercise. 00:28:46:04 - 00:28:48:02 and I can share a few with you. 00:28:48:06 - 00:28:49:12 first of all, 00:28:49:12 - 00:28:52:23 I already said this, but I think developer experience is really important. 00:28:53:00 - 00:28:58:04 What a good developer experience is might be different depending on your use case. 00:28:58:13 - 00:29:02:01 If you have tooling and you just need to make it spit out. 00:29:02:01 - 00:29:05:02 OSCAL, you may really just need like a machine 00:29:05:02 - 00:29:10:09 generated Python equivalent or whatever language equivalent of the Json schema. 00:29:10:09 - 00:29:13:15 because that would be a really short path to getting 00:29:13:15 - 00:29:16:22 OSCAL, that's pretty good. Not perfect, but pretty good. 00:29:17:00 - 00:29:20:25 My objective with the OSCAL-Pydantic library is to produce 00:29:20:25 - 00:29:24:12 the reference implementation of OSCAL in Python. 00:29:24:19 - 00:29:29:02 So I obviously include a lot of other stuff that that would be needed for that. 00:29:29:06 - 00:29:31:11 Identify the key features of the API. 00:29:31:11 - 00:29:34:11 For me, extensibility was a key feature. 00:29:34:11 - 00:29:36:10 And I'd spent a couple of months 00:29:36:10 - 00:29:39:27 trying out different approaches until I found one that, 00:29:39:27 - 00:29:43:18 allowed me to extend the OSCAL specification 00:29:44:05 - 00:29:46:28 very trivially in the appropriate ways. 00:29:46:28 - 00:29:50:27 So, you can't extend everything, but you can extend some things, 00:29:51:01 - 00:29:54:08 do spend some time looking at the schema specification. 00:29:54:08 - 00:29:55:28 or the official documentation. 00:29:55:28 - 00:29:58:28 Don't exclusively rely on Json schema. 00:29:59:01 - 00:30:02:11 It is perfectly appropriate for some use cases, but 00:30:02:17 - 00:30:05:27 it is incomplete, so be aware that it is not complete. 00:30:06:00 - 00:30:08:03 don't be afraid to start by hand coding. 00:30:08:03 - 00:30:11:01 I don't know if any of you would be afraid to start by hand coding, but, 00:30:11:03 - 00:30:15:03 the meta schema specification is comprehensive and complete. 00:30:15:03 - 00:30:17:04 But it is. It is its own thing. 00:30:17:04 - 00:30:20:03 And, if you, like me, haven't spent 00:30:20:03 - 00:30:24:09 a whole lot of time in XML, it takes some time to come up to speed. 00:30:24:09 - 00:30:26:17 and so those are, those are my recommendations. 00:30:26:17 - 00:30:29:22 Obviously there are a lot more a lot of them are encoded in my code. 00:30:29:22 - 00:30:31:03 And I'm very happy. 00:30:31:03 - 00:30:34:21 if anyone has any questions about my code or decisions I made, obviously 00:30:34:21 - 00:30:35:15 after this bit 00:30:35:19 - 00:30:37:27 Finally, a quick call for collaboration. 00:30:37:27 - 00:30:38:29 A lot of libraries need your help 00:30:38:29 - 00:30:40:07 Mine. Right. 00:30:40:07 - 00:30:41:22 but others too. 00:30:41:23 - 00:30:43:08 these are great places to start with. 00:30:43:08 - 00:30:44:22 There's OSCAL club. 00:30:44:22 - 00:30:50:06 BLOSSOM-OSCAL, OSCAL.io has the tools package, and those both have libraries and 00:30:50:06 - 00:30:53:21 applications and lots and lots of places where OSCAL work is being done. 00:30:54:04 - 00:30:57:01 maybe you'll find somebody that's working on a project 00:30:57:01 - 00:30:58:25 that you can help instead of having to write your own. 00:30:58:25 - 00:31:01:10 So, you should you should do that if you can. 00:31:01:10 - 00:31:03:12 Something I discussed in my last presentation on 00:31:03:13 - 00:31:04:08 OSCAL-Pydantic 00:31:04:08 - 00:31:08:15 But I think that there's a lot of, need for good test artifacts. 00:31:08:15 - 00:31:10:22 to be able to ensure that if you're, 00:31:10:22 - 00:31:13:13 if you're using the Json schema to produce 00:31:13:16 - 00:31:17:18 your code, to be able to have edge cases that will let you catch things 00:31:17:18 - 00:31:20:18 that are part of the schema so that so that you understand 00:31:20:19 - 00:31:23:22 when and where your library is going to produce code that 00:31:23:22 - 00:31:26:05 passes your library, but isn't actually valid OSCAL 00:31:26:12 - 00:31:28:24 that's something I've worked on as part of my library. 00:31:28:26 - 00:31:30:29 I haven't broken it out and made it its own project, 00:31:30:29 - 00:31:34:20 but anybody is welcome to steal anything you'd like to steal. 00:31:34:28 - 00:31:37:08 And that is all, for my presentation. 00:31:37:08 - 00:31:38:06 thank you so much for your time.