Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identity definition too narrow #1

Open
cronical opened this issue Feb 25, 2019 · 15 comments
Open

Identity definition too narrow #1

cronical opened this issue Feb 25, 2019 · 15 comments

Comments

@cronical
Copy link
Contributor

"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.

@GrahamWilliamson
Copy link

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.

@jwilleke
Copy link

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.

@GrahamWilliamson
Copy link

GrahamWilliamson commented Apr 10, 2020 via email

@jwilleke
Copy link

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.

@GrahamWilliamson
Copy link

GrahamWilliamson commented Apr 12, 2020 via email

@jwilleke
Copy link

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.

@cronical
Copy link
Contributor Author

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.

@cronical cronical reopened this Apr 13, 2020
@jwilleke
Copy link

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".

@GrahamWilliamson
Copy link

GrahamWilliamson commented Apr 14, 2020 via email

@jwilleke
Copy link

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 ???"

@GrahamWilliamson
Copy link

GrahamWilliamson commented Apr 15, 2020 via email

@meneer
Copy link

meneer commented Apr 17, 2020

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:

  • People identities are managed in the Joiner-Mover-Leaver processes of an organization. Either own personnel, or contractors.
  • Things come from other processes: the Change Management process. That could include a subprocess like product/software/thing development, or procurement of these things. And they are managed in a CMDB. Things can even consist of different things, making is vital to know the configuration of the thing and it's authorizations.

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 :)

@GrahamWilliamson
Copy link

GrahamWilliamson commented May 5, 2020 via email

@jwilleke
Copy link

jwilleke commented May 6, 2020

I am represented as Jim at Willeke dot com and various other Digital Identities. ;)

@meneer
Copy link

meneer commented May 8, 2020

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 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants