Open cronical opened 5 years ago
An identity is a person. A thing is really an entity i.e. a temperature sensor is an entity with an identifier. An identity has different identifiers (better term "attributes") in different contexts. But it's still the same identity. We must not restrict the concept of identity to access control. There are multiple business processes to be supported by an IAM environment.
I disagree. An Identity, or better a "Digital Identity" which is a subset of attributes within an given context that represent "thing". An Digital Identity is a Thing. A person is also a thing. Looking at any form of Identity based solely on person is short sided and not the current state of reality.
Oh Jim! You’re a thing? Look – People, including you, have an identity (I argue that a person has only one identity but I’ve been criticized for that). This identity is recognised in different ways depending what ‘domain’ you’re in i.e. my bank only cares about my account number not my staff identity. My work only cares about my staff identifier not my bank account number (some would argue that’s two identities but I don’t buy that). Identities can do all sorts of things – they can log onto computers as users or admins, access databases and get different information depending on the identifier(s) they use, and they can change their information (address, bank account, even their name in some circumstances). Things can’t do that Jim – they are totally different. They need and identifier and they must be managed, but you don’t need them to be able to alter the way they identify themselves, change their entitlements to applications and they don’t go on vacation and need a temporary re-assignment of their access. To treat things as though they are identities will create difficulty for you. And we’ve got enough of that. Thx. Graham
From: Jim Willeke notifications@github.com Sent: Friday, 10 April 2020 8:41 PM To: IDPros/bok bok@noreply.github.com Cc: GrahamWilliamson grahamwilliamson1@outlook.com; Comment comment@noreply.github.com Subject: Re: [IDPros/bok] Identity definition too narrow (#1)
I disagree. An Identity, or better a "Digital Identity" which is a subset of attributes within an given context that represent "thing". An Digital Identity is a Thing. A personhttps://schema.org/Person is also a thing. Looking at any form of Identity based solely on person is short sided and not the current state of reality.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/IDPros/bok/issues/1#issuecomment-611979051, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALCHYI6CCXVBEBFTD7XLTGTRL3ZSDANCNFSM4G2EDSCQ.
I agree there is a lot of discussion on these subjects and a lot of different terms used in often careless ways.
As far as Digital Identity goes, I am just a thing like any other entity and treating else than another Digital Identity will create difficulty for you. ;).
Of course there are different attributes for different things. But they should be treated, for the large part as the same.
My views (of course) are: A Person is a "Human Being". Humans are represented in the Digital world as a Digital Identity.
Digital Identity is what binds a person (or a thing) to his or her reputation, and reputation is what earns that person trust within the community, which in turn facilitates or inhibits that individual’s actions depending on their level of trust.
Digital Subject is the Identity Correlation of one or more Digital Identities into one entity within a context.
So at work you have more than likely, one digital Identity for logging into you Windows account and yet another digital Identity for logging into Human Resources. All of these digital Identities at work combined a Digital Subject for the context of work. There is hopefully, but in reality not always, one Attribute which is common across all your Digital Identities at work.
Certainly a piece of code can "access databases" and even bank Accounts. And as we all know, things access data on computers all the time. In many large organizations these "System" or Generic" accounts are created by the IDM system with an attribute which implies they are not a person but are otherwise created in the same fashion. They have "Entitlements" and these "Entitlements" can change over time. And if one of these "Things" moves to another location it would be possible their "Address" might be changed.
A smartWatch certainly provides data to a datastore, probably owned by the vendor, and certainly provides credentials to do so. The smartwatch updates its "Location" (i.e Address) on a regular basis. For some smartWatches I can also allow this smartWatch to send data to another dataStore. For each of these actions they need the proper entitlements.
This same smartWatch can access financial information. I provide the Authorization for this smartWatch to be have the "entitlement" to be able to make payments on my behalf.
Remote "Control" management agents do logon work computers and they must have the entitlements that allow them to do so.
Hi Jim; Thanks for the reply – comments below>> Look – I’ve agreed to do a 1st attempt at the “non-human” chapter of the BoK. Maybe you’d act as a reviewer/contributor? Thx. Graham
From: Jim Willeke notifications@github.com Sent: Saturday, 11 April 2020 7:03 PM To: IDPros/bok bok@noreply.github.com Cc: GrahamWilliamson grahamwilliamson1@outlook.com; Comment <comment@nore. ply.github.com> Subject: Re: [IDPros/bok] Identity definition too narrow (#1)
I agree there is a lot of discussion on these subjects and a lot of different terms used in often careless ways.
As far as Digital Identity goes, I am just a thing like any other entity and treating else than another Digital Identity will create difficulty for you. ;).
I’m betting you have quite a complex series of identity data (bank, workplace, subscriptions, social media etc.). These will have differing levels of authentication assurance to match the sensitivity of the resource your accessing – tell me what ‘thing’ has that complexity of multiple system access?
Of course there are different attributes for different things. But they should be treated, for the large part as the same.
I’m sure you don’t do that.
My views (of course) are: A Person is a "Human Being". Humans are represented in the Digital world as a Digital Identity.
Multiple digital identities (single identity:-)
Digital Identity is what binds a person (or a thing) to his or her reputation, and reputation is what earns that person trust within the community, which in turn facilitates or inhibits that individual’s actions depending on their level of trust.
Yes – but 1) your reputation with your bank is very different than your reputation with Facebook and 2) entities don’t earn trust.
Digital Subject is the Identity Correlation of one or more Digital Identities into one entity within a context.
Digital subject usually refers to your identity in a specific domain. This get’s difficult for a teacher in a school with his/her children in the school. There will be two digital subjects for the same person. One will have teacher access to the learning management system, the other will have parent access to the courseware for the subjects in which the children are registered.
So at work you have more than likely, one digital Identity for logging into you Windows account and yet another digital Identity for logging into Human Resources. All of these digital Identities at work combined a Digital Subject for the context of work. There is hopefully, but in reality not always, one Attribute which is common across all your Digital Identities at work.
You would typically be the same digital subject in this case, the governance system needs to be able to map your entitlements across all corporate applications. There would be many attributes that would be common across applications.
Certainly a piece of code can "access databases" and even bank Accounts. And as we all know, things access data on computers all the time. In many large organizations these "System" or Generic" accounts are created by the IDM system with an attribute which implies they are not a person but are otherwise created in the same fashion. They have "Entitlements" and these "Entitlements" can change over time. And if one of these "Things" moves to another location it would be possible their "Address" might be changed.
It’s quite rare for a system or generic account to be provisioned by the IDM system. It’s usually done by IT staff when an application or resource is commissioned. I will agree that in some cases generic accounts are managed by the PAM in order to rotate passwords periodically but this is only a stop-gap measure since generic accounts are bad practice. No one should be using generic accounts anymore.
A smartWatch certainly provides data to a datastore, probably owned by the vendor, and certainly provides credentials to do so. The smartwatch updates its "Location" (i.e Address) on a regular basis. For some smartWatches I can also allow this smartWatch to send data to another dataStore. For each of these actions they need the proper entitlements.
You’re confusing a ‘thing’ with a client. In the example you give the watch is not logging on – you are logging on (using your watch).
This same smartWatch can access financial information. I provide the Authorization for this smartWatch to be have the "entitlement" to be able to make payments on my behalf.
Nope. I know of no financial institution that would give a watch an account.
Remote "Control" management agents do logon work computers and they must have the entitlements that allow them to do so.
Need to be more specific – a SoC management tool might periodically connect to a database to pull back system data but ‘entitlement’ is not the right word. It suggests that the access has been approved based on the entity’s position or training, and that it can be changed. But of course it isn’t and it can’t. These sort of deployments are bad practice – such access should be using an API these days.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/IDPros/bok/issues/1#issuecomment-612371994, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALCHYI5YNJNIIYWMGU3PW4DRMAW3HANCNFSM4G2EDSCQ.
You say >Multiple digital identities (single identity:-) but then go on to say:
Your reputation with your bank is very different than your reputation with Facebook Agreed and there is hopefully NO connection between these two separate "Identities"
entities don’t earn trust. Every identity within Facebook has a reputation just as every Digital identity at the bank has a reputation. I have not been in a physical" bank in more 10 years. I am just a Digital Identity to the bank. Every access control system SHOULD have a reputation system, we have a lot of "fancy" mostly marketing terms for them Like Adaptive Policy-based Access Management (APAM) and Context based access control systems but they all gather data about the behavior of the Digital Identity (which might be a BOT) and build a "Reputation" (which is a core value of Trust) for the digital identity.
Digital subject usually refers to your identity in a specific domain. I agree. As you define that the Identity is the collection of all the user entries (each Digital Identity) in all the systems within a defined Context. But in REAL Life, there are always those application which hold a separate Digital Identity that is NOT controlled in the "Ideal IDM" system.
It’s quite rare for a system or generic account to be provisioned by the IDM system. I have worked on hundreds of IDM systems in real life where this was done. These Digital Identities follow the same life-cycle as all the employees and contractors which can be revoked and they all have password policies assigned. The terms of "System" or "Generic" is very dependent on the context. In this case I was implying NOT a Human.
>You’re confusing a ‘thing’ with a client. In the example you give the watch is not logging on – you are logging on (using your watch). No I am not. I Delegate Permissions (i.e Provide an Entitlement) to the Client and I assume we always authorize the client and Authorization Requires an Identity.
I know of no financial institution that would give a watch an account. No, but they must, in some Jurisdictions, authorize "agents" (EU in PSD calls them Third Party Payment Service Providers) to access my account. And that same regulation require these "agents" to authenticate which requires a Digital Identity.
Need to be more specific Every Organizations System Management agent has an account on Every Machine or mobile device that updates a software or otherwise makes changes to the device.
An Entitlement are the privileges needed for an entity to perform their job(s). These entities may not represent humans.
An identity by definitions in dictionaries is: "the fact of being who or what a person or thing is." This is represented in digital systems as a Digital Identity and trying to differentiate the between Humans represented by a "Digital Identity" vs a BOT or other Digital entity is one area where Identity Management and Access control systems are failing. Any digital identity that is trying to Access a system needs to be evaluated as an entity. We have no idea if the credentials have been stolen or otherwise compromised. Most compromised credentials assigned to a "Person" are from stolen credentials which are being presented by a BOT and NOT a person.
This is a great conversation. I'm glad to see it. It would be wonderful to achieve clarity on the meaning of various terms. Graham has a preference for Identity being reserved for humans. Jim seems to want to extend that to software agents, devices etc. Those are the things Graham likes to call Entities. Did I get that right?
The smart watch example touches on the notion of Agent and Principal. I think Client was tossed in for good measure. I've recently run into some trouble with Apple's Catalina version of MacOS, where they restrict access by software agents in a way that is orthogonal to the rights of the operator. This is under the heading of privacy. I'd love to see definitions that can support this concept.
I'm going to reopen this issue, since you two provided a lot of fodder to consider. My goal is to further the conversation in the hopes of eventually coming to a set of definitions that IDPro as whole can endorse.
I think that is right.
Entities includes all "Things". All "Things" must be involved Access Control must be Identified and therefore must have a Digital Identity even if they are allocated to the "Anonymity Set".
Hi Jim; Can you give a use case where a “thing” can be anonymous? I think anonymity is a privacy construct that’s applicable to identities i.e. people. NIST did us a dis-service with a 4 level assurance model. Some governments added a fifth – Anonymous or Pseudonymous i.e. a company cannot ask for my PII if the service I’m requesting does not need it. That’s the law in many jurisdictions. I can’t see how it applies to devices that must identify themselves. Thx. Graham
From: Jim Willeke notifications@github.com Sent: Tuesday, 14 April 2020 7:29 PM To: IDPros/bok bok@noreply.github.com Cc: GrahamWilliamson grahamwilliamson1@outlook.com; Comment comment@noreply.github.com Subject: Re: [IDPros/bok] Identity definition too narrow (#1)
I think that is right.
Entities includes all "Things". All "Things" must be involved Access Control must be Identified and therefore must have a Digital Identity even if they are allocated to the "Anonymity Set".
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/IDPros/bok/issues/1#issuecomment-613330651, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALCHYI236PIVC4JQMFYV5KLRMQUEBANCNFSM4G2EDSCQ.
Anonymous Identity is a Digital Identity that is essentially Anonymous and is therefore part of the Anonymity Set.
Perhaps all we know is a cookie value so we know they were here before or we may have a Device Fingerprint, but Identification of the Digital Identity can not be separated from the Anonymity Set with any Level Of Assurance (Which is Authorization)
So any "thing" on a network (or the Internet) that is not Authenticated Identified is in "Anonymity Set" and therefore anonymous.
For instance I have network devices that show any MAC address on the network. (Even if they have no IP Address) Sometimes it is just a Neighbor near my Wi-Fi (or even a neighbors Wi-Fi broadcasting) and network detection devices show a "In Range".
I say "Identification is any process that is able to distinguish (or perform Recognition) of a specific Digital Identity within a specific Context from the Anonymity Set to a given Level Of Assurance" and "Authentication (AuthN) is the process of establishing to a specified Level Of Assurance that the Identification is authentic."
So these device on my network have been Identified. I might know their MAC Address. But they could be spoofing that. I have no level of Assurance for the Identification and therefore they are (in my specific context) part of the Anonymity Set. So authentication and Identification are in reality the same with differing "Levels Of Assurances"(Generic use of the term Levels Of Assurance) and all of this is dependent on the context. The level of assurance at any organization maybe different. What is applicable for my home network Might not work so well for the FBI.
Interestingly, we tend to call these devices until a Digital Identity Authenticates and then THAT SAME Device is now considered a "Person". But I have never seen a "Person" on the Network. I have never seen a Person that has a MAC address. When I thought about this is when I started specific use of Digital Identity. It is NOT a "Person". It is only an abstract construct of an entity that contains some Attributes about the "Entity".
I tend relegate "Identity" as a psychological interest.
BTW: Naming things is hard. My fear is that the Body of Knowledge (BoK) uses terms which are essentially the same things with some added attributes which makes things very confusing and intimidating to new folks or casual readers. I participate in several Standards workgroups and of course they love their 3-6 letter Abbreviations and acronyms. But in something like a Standard or this BoK (which is Bank of Oklahoma right?) I thing Abbreviations and acronyms should be noted but not used. We have all been reading along and run into these and had to stop and Google to find out; "Sure I knew that but called that ???"
Thanks Jim. I understand. Thx. Graham
From: Jim Willeke notifications@github.com Sent: Wednesday, 15 April 2020 8:09 PM To: IDPros/bok bok@noreply.github.com Cc: GrahamWilliamson grahamwilliamson1@outlook.com; Comment comment@noreply.github.com Subject: Re: [IDPros/bok] Identity definition too narrow (#1)
Anonymous Identity is a Digital Identity that is essentially Anonymous and is therefore part of the Anonymity Set.
Perhaps all we know is a cookie value so we know they were here before or we may have a Device Fingerprint, but Identification of the Digital Identity can not be separated from the Anonymity Set with any Level Of Assurance (Which is Authorization)
So any "thing" on a network (or the Internet) that is not Authenticated Identified is in "Anonymity Set" and therefore anonymous.
For instance I have network devices that show any MAC address on the network. (Even if they have no IP Address) Sometimes it is just a Neighbor near my Wi-Fi (or even a neighbors Wi-Fi broadcasting) and network detection devices show a "In Range".
I say "Identification is any process that is able to distinguish (or perform Recognition) of a specific Digital Identity within a specific Context from the Anonymity Set to a given Level Of Assurancehttps://ldapwiki.com/wiki/Identification" and "Authentication (AuthN) is the process of establishing to a specified Level Of Assurance that the Identification is authentic.https://ldapwiki.com/wiki/Authentication"
So these device on my network have been Identified. I might know their MAC Address. But they could be spoofing that. I have no level of Assurance for the Identification and therefore they are (in my specific context) part of the Anonymity Set. So authentication and Identification are in reality the same with differing "Levels Of Assurances"(Generic use of the term Levels Of Assurance) and all of this is dependent on the context. The level of assurance at any organization maybe different. What is applicable for my home network Might not work so well for the FBI.
Interestingly, we tend to call these devices until a Digital Identity Authenticates and then THAT SAME Device is now considered a "Person". But I have never seen a "Person" on the Network. I have never seen a Person that has a MAC address. When I thought about this is when I started specific use of Digital Identity. It is NOT a "Person". It is only an abstract construct of an entity that contains some Attributes about the "Entity".
I tend relegate "Identity" as a psychological interest.
BTW: Naming things is hard. My fear is that the Body of Knowledge (BoK) uses terms which are essentially the same things with some added attributes which makes things very confusing and intimidating to new folks or casual readers. I participate in several Standards workgroups and of course they love their 3-6 letter Abbreviations and acronyms. But in something like a Standard or this BoK (which is Bank of Oklahoma right?) I thing Abbreviations and acronyms should be noted but not used. We have all been reading along and run into these and had to stop and Google to find out; "Sure I knew that but called that ???"
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/IDPros/bok/issues/1#issuecomment-613947199, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALCHYI537NZGGCAEP2UYJNLRMWBSVANCNFSM4G2EDSCQ.
I would like to add to the confusion. Or help fixing it.
Let's add the term object and subject In my opinion things can be both object and subjects. Either, as an object, they are managed, configured, read just like any other object or resource. And in the access policy is managed how to allow subjects (users, processes, systems, tools, streams) to get access to a thing, to manage it. In the same manner a thing can be a subject that needs to get access to data, other things, resources, processes, you name it. In essence a thing can be just like a person. These things are RPA's , processes, robots, cars, whatever.
Big difference is:
I wrote a white paper about Adaptive Access and tried to leave this terminology aside by introducing new terminology: The Access Requester and the Access Supplier (as a consultant you have to come up with your own models :) ). (the whitepaper is in background materials: https://drive.google.com/open?id=16W0MeQCcE8nMuxnfUj54pNSyYXInUFkG)
These terms make it possible to do away with things or persons, that's not relevant for access. The Identity management lifecycle, results in personal identities in an IGA environment and Change Management, results in a CMDB.
This makes it possible to also manage non-personal accounts. A root account is not an account as we have the personal accounts, root is an authorization. Root exists because of a change in IT that leads to a new linux server and it's root account. I explained this in https://drive.google.com/open?id=1yZgoqmgxYA8-76XjMHL5-qFegA-dEJc4
Does this help? Personal identities are managed in an IGA environment, by an Identity Provider, non-personal identities are managed in a CMDB, by the Change Management process. If a thing needs access, that will have to be configured in the thing and access control will have to manage that in a Policy Based Access Control environment (PEP, PDP, whatever).
My latest presentations are about Granting Access Without an Account. That really challenges the audience :)
Hi Jim. I’ve have a short draft article on non-human account management – do you have time to review and advise? If so – what email can I use? Thx. Graham
From: Jim Willeke notifications@github.com Sent: Sunday, 12 April 2020 6:46 PM To: IDPros/bok bok@noreply.github.com Cc: GrahamWilliamson grahamwilliamson1@outlook.com; Comment comment@noreply.github.com Subject: Re: [IDPros/bok] Identity definition too narrow (#1)
You say >Multiple digital identities (single identity:-) but then go on to say:
Your reputation with your bank is very different than your reputation with Facebook Agreed and there is hopefully NO connection between these two separate "Identities"
entities don’t earn trust. Every identity within Facebook has a reputation just as every Digital identity at the bank has a reputation. I have not been in a physical" bank in more 10 years. I am just a Digital Identity to the bank. Every access control system SHOULD have a reputation system, we have a lot of "fancy" mostly marketing terms for them Like Adaptive Policy-based Access Management (APAM) and Context based access control systems but they all gather data about the behavior of the Digital Identity (which might be a BOT) and build a "Reputation" (which is a core value of Trust) for the digital identity.
Digital subject usually refers to your identity in a specific domain. I agree. As you define that the Identity is the collection of all the user entries (each Digital Identity) in all the systems within a defined Context. But in REAL Life, there are always those application which hold a separate Digital Identity that is NOT controlled in the "Ideal IDM" system.
It’s quite rare for a system or generic account to be provisioned by the IDM system. I have worked on hundreds of IDM systems in real life where this was done. These Digital Identities follow the same life-cycle as all the employees and contractors which can be revoked and they all have password policies assigned. The terms of "System" or "Generic" is very dependent on the context. In this case I was implying NOT a Human.
You’re confusing a ‘thing’ with a client. In the example you give the watch is not logging on – you are logging on (using your watch). No I am not. I Delegate Permissions (i.e Provide an Entitlement) to the Client and I assume we always authorize the client and Authorization Requires an Identity.
I know of no financial institution that would give a watch an account. No, but they must, in some Jurisdictions, authorize "agents" (EU in PSD calls them Third Party Payment Service Providers) to access my account. And that same regulation require these "agents" to authenticate which requires a Digital Identity.
Need to be more specific Every Organizations System Management agent has an account on Every Machine or mobile device that updates a software or otherwise makes changes to the device.
An Entitlement are the privileges needed for an entity to perform their job(s). These entities may not represent humans.
An identity by definitions in dictionaries is: "the fact of being who or what a person or thing is." This is represented in digital systems as a Digital Identity and trying to differentiate the between Humans represented by a "Digital Identity" vs a BOT or other Digital entity is one area where Identity Management and Access control systems are failing. Any digital identity that is trying to Access a system needs to be evaluated as an entity. We have no idea if the credentials have been stolen or otherwise compromised. Most compromised credentials assigned to a "Person" are from stolen credentials which are being presented by a BOT and NOT a person.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/IDPros/bok/issues/1#issuecomment-612583406, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALCHYI3XTHMZQNLVXG4HMH3RMF5VLANCNFSM4G2EDSCQ.
I am represented as Jim at Willeke dot com and various other Digital Identities. ;)
I am represented as Jim at Willeke dot com and various other Digital Identities. ;)
Good to mention... I am André Koot, or @meneer, or @mijnheer :-)
"Our scope is to define identity so that it can be used as a means to get access to protected resources."
Ref: https://github.com/IDPros/bok/blob/bok-edit/Introduction/Identification%20and%20Authentication/Context%20and%20Identity.md
The counter example that comes to mind is the use of identity to evaluate statements. For instance viewing Twitter feeds, there is no resource that is apparent, but I evaluate what I read based on who says it.
The statement may be valid in the context of enterprises protecting resources, but probably needs a more universal feel at least at the top level.