Who I Claim to Be vs. Who You Think I Am
In
response to my blog yesterday, Rohan
Pinto stated that the correct response to an Identity claim should be "who
I think you are." Furthermore, the level of proof necessary to validate
my claim depends upon whether I’m offering something of value to you
or requesting something of value from you. I like that reasoning.
So, first comes my claim – "this is who I am, and this is what I offer
or request." Then comes your question – "who do I think he is, and
what does he want or offer?" Therein lies the big challenge for authentication
(do I believe him?) and authorization (what do I trust him to do?).
While the burden of proof for a claim lies with the subject that makes the
claim, the decision about how deep that proof must be and what transactions
will be authorized lies with the receving subject.
Last night I was with a group of my peer Identarati
from Sun cruising on beautiful Lake
Austin, near Austin, Texas. One
guy mentioned a customer requirement that Sun’s Access
Manager product should grant a user access to a financial application only
on weekdays between 8 a.m. and 5 p.m. and only if he or she had authorization
to deal with transactions over $100,000. (something like that)
In this scenario, the user would assert his claim – presumably user name and
password – and the Access Manager product would need to make the following decisions:
- AIs the claim believable to an acceptable
level of proof? (authentication) - Is this person allowed to access this system at all? (authorization)
- Is the current time within the authorized time frame? (authorization)
- Is this person authorized to deal with transactions over $100,000? (authorization)
Claim. Authentication. Authorization. It works for me!
Tags: Identity
Digital Identity
Identity Management
Identarati
RohanPinto
Sun Microsystems
Access Manager
Austin
LakeAustin
And the good news is – that is still consistent with the SAML-oriented model I have been babbling on about:
Level 1: an assertion of identity, based on presentation of credentials;
Level 2: an assertion of entitlement, based on access control profiles;
Level 3: assertions about transaction-related attributes, such as valid time of day and transaction limit.
A relevant distinction, I think, is that in this case, the L1 and L2 assertions are both directly ‘about’ characteristics of the person requesting the service; the L3 assertions are ‘about’ other attributes (in that ‘time’ and ‘amount’ are not attributes of the person…), but still bearing in mind who is making the request.
I also think it bears noting that the ‘requester’ is not making any decisions here… they are just making assertions. It’s the service provider who is making a series of linked decisions.
HTH,
Robin
Robin:
As always, great comments. Thanks for your quick response.
Do you think that Level 3 assertions should normally be managed by a product such as Access Manager, or should they be managed by the application that is accessed?
Thanks,
Mark
The problem I have with Level 3 emerges when the systems are distributed and the system requesting the authorization is permitted no direct acess to user information.
So lets take the example of a vendor who wants to ensure that some user has an account at bank x AND that they have a balance greater than Y.
In this case the bank is the only trusted entity.
The information about the balance of the user belongs to the user and the bank cannot offer it up to the vendor without the user’s permision. The vendor also cannot directly authenticate the user but must rely on the bank to authenticate.
Here is how the transaction might work in this case.
The vendor asks the user to provide identity. The user obtains authenticated (signed) identity from the bank and gives it to the vendor.
The vendor asks the user to provide proof they have a sufficient ballance. Again the user asks for signed authentication of the same and gives it to the vendor.
This allows the bank to offer secure information only to the user. The vendor’s interactions go through the conduit of the user but the truth of the users assertions are authenticated by the bank.
The user remained in control of his information. If the vendor were allowed to use the authentication provided by the user to make ANY queries of the bank, the vendor would then have access to information inappropriately. The user would be giving out more than was asked.
[Trackback] Please read the following chain prior to proceeding..
Mark Dixon’s post on ” Who I Am vs. Who I Claim to Be ” My prior post on ” You are who I say you are ” Mark Dixon’s response at ” Who I Claim to Be vs. Who You Think I Am ”
Well, I…
Kevin:
Thanks for your comment. It is interesting that you chose the example of a bank being a trusted partner.
In a recent blog, I wrote of the Sxip Identity system:
http://blogs.sun.com/roller/page/identity?entry=i_know_dick
Dick Hardt of Sxip told me that in their model of user-centric Identity a bank might very well assume the role of a “Homesite,” a trusted third party. Because banks already have trusting relationship with their customers, it was a natural next step for them to become trusted third parties in an online authetication sequence.
In your example, of course, the role of the bank goes beyond simple validation of user credentials – it validates a user’s claim of finacial capacity to complete the transaction.
Mark