 Thank you for viewing this presentation called The Art of Attributes. The goal is to help a community of interest to use attributes well. I've been working in the fields of attributes now for many years and a few lessons have been gleaned that I hope to pass on. I want to begin by talking about the distinctions between identifiers and attributes. We want to avoid some deep order about attributes because this is a focused session. I'd like to look then at the intrinsic issues in sharing attributes. Where the art of attributes is being practiced. I want to talk a little bit about the access control use cases, which are very important, and normative bundles of attributes. There's a new and growing interest in topics like competencies, micro degrees, other kinds of credentials, and how those kinds of edges relate to both attributes and verifiable credentials. And we'll close with a few observations and actionable items. Identifiers are one-to-one correspondence with this subject. That's the key aspect of that, of being an identifier. When you talk about identifiers, we often talk about whether that connection of the identifier to the subject is a well vetted one, especially in the case of humans. Whether it's reassignable or not, can that email address be reassigned to someone else. And then uniqueness. Identifiers one-to-one, but it's within a particular domain. And so how do we describe that? There's a set of characteristics about attributes that are increasingly under discussion, especially in CNI circles. There's conversations around anonymous attributes. I'm sorry, anonymous identifiers, pseudonymous identifiers. The identifier that you often see on a screen that could be your display name. And then some new privacy preserving approaches around pair-wise distinct identifiers so that correlation attacks are minimized. It should be noted that identifiers are used in other parts of the stack beyond the particular dimension we're looking at. For example, session IDs are used by web sessions and web fingerprints are often used, not particularly with integrity, to track users between sites. Attributes, on the other hand, are often one-to-many. And usually that one-to-many aspect, one attribute can be shared by many different subjects, gives you a lot of benefit in privacy and security. It gives you access control at scale, both fine grain to individual pages on a wiki, for example, and coarse grain to the resource, the wiki itself. Attributes can provide personalization. They can serve to offer compliance and regulatory benefits to an enterprise that needs to comply with these kinds of rules. And finally, as just mentioned, attributes can be used as skills and competency and certifications, and having those kinds of attributes is very useful in an increasingly online world. Some things we're not going to talk about today. We're not going to talk about the level of assurance about the value of an attribute. How confident is either the relying party or the issuer of that attribute to that subject? How confident are they of that binding? The shelf life, how long is the attribute good for? And other metadata type concerns about the attributes. Right now, they're best handled out of band. But we're not going to talk as well about re-identification of a subject from attribute aggregation. That's one of the important considerations, especially in epidemiological research, can a set of characteristics by themselves identify a subject even if no one attribute is unique to that subject. They talk about bucket sizes, and in this case, how many subjects have this collection of attributes, and that's an important consideration. We're not going to talk about that. We're not going to talk about the syntax of attributes either. It's critical. It's pretty well understood. It just needs to be paid attention to. If I'm going to be sharing attributes between an identity provider and a resource, for example, or between a user and a relying party that wants to validate that that user has that attribute, a couple of things need to be addressed. Both sides need to agree on a shared meeting, including those metadata issues that I talked about earlier. There needs to be permissions to move the attributes from the holder of the attribute to the relying party. That's often done with either consent or legitimate interest. There's a method of actually moving the attributes, several protocols. LDAP is the longstanding directory protocol to move those attributes. SAML and OAuth tokens became the federated vehicles for transporting attributes. And finally, the verifiable credentials are a new vehicle. There's standalone. They can be carried on a smartphone as the transport and then conveyed to the relying party that way. You want to make sure there's security and privacy of the transport. You want to make sure that the relying party believes in what they've received. It's meaningful and untampered. Some of those earlier considerations, as we mentioned, but is whoever issued this credential, especially in the badges instance, authorized to issue those kinds of badges to those kinds of users. Where is all this happening? It's on happening on campuses daily for both on premises applications and software as a services. What's happening in both institutional and into institutional instances in the into institutional instance is particularly important that privacy considerations get addressed. One particular conversation is going on in the seamless access contract language to translate bundles of attributes into the contracts that libraries often have with content providers to reflect these bundles of attributes. What's happening in refeds, the research and education federation community. It's international. They're the holders of such schema as edu person happening in IMS and some of the abadging work. And then within big research collaborations with complex access control needs. There is the constant discussion of moving attributes around. You need to have both institutional and individual controls of the attribute release. You'd like to use the control to be effective and informed. You'd like there to be a measure of institutional control. An interesting use case is what we call negative permissions. If a user is not permitted to use a service like a VPN, you'd like to be have that information communicated to applications such as VPN providers that need to know that information and consent should not be at play in that. Finally, the institution can reduce friction in the user experience, sometimes at the sake of user control by knowing what the belong party needs in terms of attributes. One tool that I've been working on with Duke for a while now is called car consent informed attribute release. It's an open source protocol neutral example of tools that integrate institutional and user control for permissions to release attributes. And finally, there's a concept in this space that we don't quite understand yet in our community around data minimization. What does that really mean. When do you know what's an attribute was required by the application versus optional. You can see that other verticals have done this already the advertising vertical in response to GDPR rulings from the EU have created a new set of cookies. And there are four bundles and I'm sure you've run into in your web browsing, and you need to consent to all the bundles. Speaking of bundles, they're often used together for common purposes. Sometimes the bundle will dictate with the IDP release sometimes it will dictate and form an SP about what it should ask for, and then finally it can trigger end user consent mechanisms. Attributes have proven to be tricky because there's a fair degree of semantic play in the federated ecosystem and campuses have different policies that might make an identifier non reassignable on one campus and reassignable in a different institution. So because of that, we need to in our bundles. Talk about either all choices depending upon how the institution managers is identified, identify as same concepts apply to words like at your person affiliation staff versus student faculty or called staff in the UK. The third bundle widely used today is research and scholarship. It's intended for federated login user uses for researchers. It has a set of attributes associated with it, and those get released if institution or use it chooses to release to that. There's a lot of conversations going on now in the refeds community about two new attribute bundles and anonymous authorization and it's anonymous one that are of interest to the CNI community. We started federations and federated identity for access controls. We were in a space where, when we started that you would list a set of identities about who could access a resource that quickly became unscalable and insecure as individual identities lost permissions but the access control this would not manage. We moved into role based, much more scalable, not fine grain enough. We came down to attribute based as as basically the best way to do access control that creates management challenges for the institution. And so we're moving up a level if we can to policy based saying these policies dictate the release of these attributes. These attributes typically are edge a person affiliation entitlements and is member of affiliation. It's course grain. Those are the values that can take that's course semantics and institution will decide the assignment of values. And it works. That's important. It's widely used as your person entitlements are much more sophisticated. They're give us an extensible syntax for community centered semantics. For community that wants to control access to a resource with something fine grain, like major or class membership, or citizenship, all of those are possible. Some of those values may only exist in the communication on the wire between the identity provider and the relying party others may be directory services. This will be fertile ground over the next few years as we get into access control. Finally, as member of it's a great device for doing group memberships which are very, very handy. Unfortunately, when we talk about is member of for the purpose of of access control and sharing that it's a multi value of attribute and extracting extracting the group memberships that are important for this particular use, and not sending the others is tricky. This is in micro degrees badges competencies. Great use cases ranging from skills in a chemistry class individual skills to first responders needing to have their credentials for various competencies authorized on the scene. And to make those assertions are composable. So you can do complex logic and give the true false answer offline validation in case the environment does not have internet access, which is frequently the case in these in these use cases mobility to be able to carry these kinds of credentials around on a mobile device. Unfortunately verifiable credentials as attractive as they are a suffering from blacks of standards in the wallets that contain them lack of standards and who can issue them and user identifiers contained within the credentials. And how are they bound to the subject. So, some observations, which turned out to be really important is on the wire, and the mapping of local to on the wire values with new attributes. You typically want to make the space of values that can take extensible. You'll anticipate a set of use cases and new ones will arise. These new entitlements are underutilized as a policy preserving mechanism as a community. If you want to try to do access control in a distributed fashion entitlements are an excellent tool. It's the most tragic that some technologies like decentralized identities, which are very attractive seem to not be able to converge on standards, something about the technology and the people that practice it. We have not yet reached fine grain attributes. This is challenging. And finally, anomalies are going to happen in this environment and access to drill. It's going to be unfortunate that important library resources, what attributes are released to them may depend on how you get to them. So directly it might be on one set of attributes if you're going through a portal that portal may ask for additional attributes as part of its portal nature. We have to be careful about those instances. Finally, actionable items for the CNI community. We've talked about attribute release at the institutional level. We invite your participation in that. It's an important point for privacy. We don't have a taxonomy for the purpose of use in how the relying party may use the attributes it receives. The advertising industry has been able to do that. Can we create one. They are a growing trend, but they represent many different resources behind them. How do we know which attributes a particular resource needs and only pass those through the portal to the end user, the portal shouldn't ask for everything that anybody might need behind it. As mentioned earlier, we need community standards to help us figure out what's a required attribute versus an optional attribute for an application. And finally, there's a conversation going on about distributed about reporting utilities in a federated world for libraries. Please participate if you find that of interest. Thank you for your presentation.