Downloaded 20 times
Uploaded byIan Glazer
Do we have a round wheel? Thoughts on Identity standards
The document discusses how identity management systems continually reinvent themselves as tasks and requirements change, similar to how humans reinvent the wheel. It examines how authentication, authorization, attributes, and user provisioning have evolved through multiple standards and protocols. While progress has been made, opportunities remain to adopt modern standards, help others adopt standards, demand standards from technology and service providers, and establish identity relationship management to connect organizations and services in a standards-based way. The goal is to develop interoperable, round wheels that can effectively handle the loads of relating people, devices, and things.
Do we have a round wheel? Thoughts on Identity standards
- 1. Ian Glazer Senior Director,Identity Salesforce Identity @iglazer Do we have a round wheel yet?
- 2. Why do humans continuallyreinvent what they already have?
- 3. 1. functional thing 2.attempt to “fix” it 3. break it 4. fix it 5. functional++ thing
- 4. Why is itthat we reinvent the wheel?
- 5. Eventually we geta round one.
- 6. Why do wedo this in the world of identity?
- 9. We reinvent thewheel when tasks change
- 10.
- 11.
- 12.
- 13.
- 14. IAM has tostay contemporary
- 15. The load ourIAM wheels have to carry has changed.
- 16.
- 17.
- 18.
- 19. Right Experience Right People& Things Right Time
- 20. Right Experience Right People& Things Right Time Right Place
- 21.
- 23.
- 28. Reasonably large number ofidentities with a reasonable number of attributes
- 29. We are beingasked to haul more and different identities
- 31.
- 38.
- 39.
- 40. Unreasonably large number ofidentities with a few attributes
- 42. Reports to Reports toReportsto Works with
- 43. Reports to Reports toReportsto Owns Works with Owns
- 44. Reports to Reports toReportsto Owns Owns Owns Sends data to Gets data from Owns Paired with Uses Controls Works with
- 45. Reports to Reports toReportsto Owns Owns Owns Sends data to Gets data from Owns Paired with Uses Controls Owns Uses Uses Constrains choice of Works with
- 46. Reports to Reports toReportsto Owns Owns Owns Sends data to Gets data from Owns Paired with Uses Controls Owns Uses Uses Constrains choice of Sends data to Ridden in Ridden in Works with
- 47. Unreasonably large number ofrelationships between unreasonably large numbers of people and things, each with attributes
- 49. 1. Authentication 2. Authorization 3.Attributes 4. User Provisioning
- 50.
- 51.
- 52.
- 53.
- 54. OpenID Connect could usea few more miles on the road
- 55. But you shouldstart today with it
- 58.
- 59. Can we harmonize levelsof assurance?
- 60.
- 61. myLOA 2 =urLOA 3.1
- 62. You’ve been proofed. You’vebeen authenticated.
- 63.
- 64.
- 65. Poorly deploying strong authentication makesit weak authentication.
- 66.
- 68.
- 69. 1. Reinvention 2. IAM’sCollective Shame
- 70.
- 71.
- 72.
- 73.
- 74.
- 75. The need for passwordvaulting
- 76. We’ve had fully workableauthentication standards for years
- 77.
- 78.
- 79. SP’s not actingon behalf of their customers’ interests
- 80.
- 81.
- 83.
- 84. Killing passwords is IAM’snew black
- 85. Killing the needfor password vaulting
- 86. More reasonable More achievable Moreeffective
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 94.
- 95. Things that allowyou to do anything
- 96. tend to makeit hard to do anything
- 97. Focus on thePAPs not the protocol
- 98.
- 99. REST & JSON aregood steps forward
- 101. Could be used torepresent authorization decisions
- 102.
- 104.
- 105. Still needs moremiles on the road
- 106.
- 108. How can athing make a decision with more autonomy?
- 109. How can wemake decisions closer to the place and time of use?
- 110.
- 111. Can perform actions Q,W, and E Can perform actions X, Y, and Z
- 112. Can perform actions Q,W, and E Can perform actions X, Y, and Z
- 113. Can perform actions Q,W, and E Can perform actions X, Y, and Z
- 114.
- 115.
- 116.
- 117. Authentication Round Authorization NotRound* Attributes Roundish
- 118. The Sad Magicof Commas.
- 119.
- 120.
- 121.
- 122.
- 123.
- 124.
- 125.
- 126.
- 127.
- 128.
- 129.
- 130. inetOrgPerson for a newgeneration?
- 131.
- 132. dn:cn=Barbara Jensen, ou=WhatEvs,dc=company, dc=com objectclass:top objectclass:person objectclass:hipsterOrgPerson cn: Barbara Jensen nickname: Daisy favBand: no one you’ve ever heard of whatRUHaving: Fireball with a pickleback title: social media guru twitter: @daisypop89 email: isforoldpeople@irony.aol.com postalCode: 11211 country: USA! USA! telexNumber: is that like a fax or something?
- 133. Make SCIM schema thestandard?
- 134. Standardizing schema can onlywork in communities of interest
- 136.
- 137. Authentication Round Authorization NotRound* Attributes Roundish User Provisioning Near Roundish
- 138.
- 139. SPML v2 wasnot round
- 140. DSML v2 wasround
- 141. But neither arewell suited for the modern web
- 143.
- 144.
- 145.
- 147. Needs more mileson the road
- 148.
- 149.
- 150.
- 151.
- 152. SCIM can handleboth
- 153.
- 154. How round arethe identity wheels?
- 155. Authentication Round Authorization NotRound* Attributes Roundish User Provisioning Near Roundish
- 156. Do we needthings other than wheels?
- 157. How do youdiscover the identity services of a service provider?
- 158.
- 159. How do youknow if they use
- 160.
- 161. How do weconnect our orgs and our identity services?
- 162. How do wekickstart relationships without paying p2p costs?
- 163. Hubs and axlesfor our roundish wheels
- 164. Remove the heavy liftingfor providing and consuming services
- 165. This is wherewe must go.
- 166.
- 167. People and things moreclosely related
- 168.
- 169.
- 170.
- 171. Right Experience Right People& Things Right Time
- 172. Right Experience Right People& Things Right Time Right Place
- 173. We are goingto shoulder a heavy load.
- 174.
- 175.
- 176. We need aset of design considerations.
- 177. The Laws ofRelationships • Acknowledgeable • Actionable • Constrainable • Contextual •Immutable •Provable •Revocable •Scalable •Transferrable
- 178.
- 179.
- 180.
- 181. If you don’t, youare inventing your own wheel
- 182. That is ashort-term optimized strategy at best.
- 183. If the currentones don’t work for you, bring out your use cases.
- 184. Kelly Grizzle @kelly_grizzle Nat Sakimura @_nat LeifJohansson @leifjohansson Maciej Machulak @mmachulak John Bradley @ve7jtb
- 185. 2. Help othersto adopt
- 186. Build SDKs to helppeople use OpenID and SAML
- 187. Support open source implementationsof SCIM and OAuth
- 188.
- 189.
- 190.
- 191. From your identity technologyproviders.
- 192.
- 193. From your business serviceproviders.
- 194.
- 195. From your own developerteams.
- 196.
- 197. If for noother reason than to kill off the need for password vaulting.
- 198.
- 199.
- 200. A great specis satisfying
- 201. A great specis satisfying Pamela Dingle @pamelarosiedee Chuck Mortimore @cmort Eve Maler @xmlgrrl David Brossard @davidjbrossard Susan Morrow @avocoidentity Brian Campbell @__b_c
- 202. but it isn’tthe end goal.
- 203. We reinvent thewheel,
- 204. we revisit andrebuild our standards
- 205. to get round,beautifully functioning ones
- 206. to carry theloads we must shoulder,
- 207. to get uswhere we need to go
- 208. in this eraof modern identity.
- 209.
Editor's Notes
- #3 Why do human continually seem to reinvent what they already have? Why is it that we take a reasonably functional thing and attempt to rebuild it and in doing so render that reasonably functional thing non-functional for a while? Why is it that we reinvent the wheel?
- #4 Why is it that we take a reasonably functional thing and attempt to rebuild it and in doing so render that reasonably functional thing non-functional for a while?
- #5 Because eventually, we get a round one. Anyone who has worked on technical standards, especially identity standards, recognizes this pattern. We build reasonably workable standards only to rebuild and recast them a few years later.
- #7 We do this not because we develop some horrid allergy to angle brackets, an allergy that can only be calmed by mustache braces. This is not why we reinvent the wheel, why we revisit and rebuild our standards. Furthermore, revisiting and rebuilding standards isn’t simply a “make-work” affair for this guy (insert picture of Tony in Google t-shirt
- #10 We reinvent the wheel the tasks needed of those wheels change. In IAM, the shift from SOA, SOAP, and XML to little s services, REST, and JSON was profound. And we had to stay contemporary with the way the web and developers worked. In this case, the technical load that our IAM wheels had to carry changed.
- #17 But there is a more profound change to the tasks we must perform and the loads we must transport and it too will require us to examine our standards and see if they are up to the task.
- #18 It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- #19 It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- #20 It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- #21 It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- #24 IAM is really good at a reasonable number of identities with a lot of attributes
- #25 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #26 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #27 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #28 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #33 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #34 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #35 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #36 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #37 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #38 but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- #39 25B according to Gartner.
- #40 50B according to Cisco. I guess we know who has more to gain
- #42 IAM can handle some amount relationships
- #48 But this transition is not just from managing identities of people carbon-based life forms to silicon ones. Today we are okay at managing a few relationships each with very few attributes. But what we as an industry must do is manage a completely unreasonable number of relationships between an unreasonable number of things and each of these relationships has a fair number of attributes of their own. That, my friends, is a heavy load to haul.
- #49 Let’s consider identity standards and their “roundness” Image courtesy of NARA: https://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/As_this_big_pile_of_used_auto_tires_indicates%2C_the_United_States_with_its_many_passenger_cars_has_in_discarded_tires..._-_NARA_-_535587.tif/lossy-page1-1244px-As_this_big_pile_of_used_auto_tires_indicates%2C_the_United_States_with_its_many_passenger_cars_has_in_discarded_tires..._-_NARA_-_535587.tif.jpg
- #51 Overall, I’d say the authentication wheel is round, maybe could use a little air, but its round. We’ve got multiple protocols, multiple standards, which is both a reflection of the complexity of the problem and the maturity of the problem. Now some of these protocols do need a few more miles on them – OpenID Connect but by no means does this mean you shouldn’t use it today. Expect new profiles over time but you certainly can get going today. And where OpenID Connect cannot take you, trusty SAML still can. Although authentication is okay, representing assurance isn’t. I wonder if we need to harmonize level of assurance. I also wonder if this is even possible. Knowing that a person was proofed and how they were authenticated is nice, but as Mark D will be the first to tell you deployment matters. You can deploy a strong auth technology poorly rendering into a weaker state. So knowing your LOA 3 is my LOA 2.25 might not be useful. More importantly, I wonder how small and medium sized organizations, those without a resident identity dork, figure out what LOA to require, what trust framework to use, and how to proceed. This to me, seems like a place for the IDESG and its ilk. And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity. Second, the fact that password vaulting exists at this point in history is an embarrassment. To be clear, I am not saying that password vaulting solutions and vendors are an embarrassment. The fact that, having had workable authentication standards for this many years and we still have password vaulting is an embarrassment to our profession. It means that identity vendors have not done enough to enable service providers. It means that service providers still exist who do not want to operate in the best interest of their enterprise customers. At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.) The existence of password vaulting means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands. I know we are all trying to kill the password but I think a more reasonable, more achievable, and more effective goal is to eliminate the need for password vaulting through the use of authentication and federated SSO standards. By 2020, if I am still saying this, we have failed.
- #52 Authentication’s wheel is round! Could use a bit of air but pretty good
- #56 Expect new profiles over time but you certainly can get going today.
- #57 If OpenID Connect can’t get you there today…
- #58 SAML can
- #59 Although authentication is okay, representing assurance isn’t. I wonder if we need to harmonize level of assurance. I also wonder if this is even possible. Knowing that a person was proofed and how they were authenticated is nice, but as Mark D will be the first to tell you deployment matters. You can deploy a strong auth technology poorly rendering into a weaker state. So knowing your LOA 3 is my LOA 2.25 might not be useful. More importantly, I wonder how small and medium sized organizations, those without a resident identity dork, figure out what LOA to require, what trust framework to use, and how to proceed. This to me, seems like a place for the IDESG and its ilk.
- #63 Knowing that a person was proofed and how they were authenticated is nice
- #66 So knowing your LOA 3 is my LOA 2.25 might not be useful.
- #67 More importantly, I wonder how small and medium sized organizations, those without a resident identity dork, figure out what LOA to require, what trust framework to use, and how to proceed. This to me, seems like a place for the IDESG and its ilk.
- #68 IDESG to the rescue?
- #69 And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity. Second, the fact that password vaulting exists at this point in history is an embarrassment. To be clear, I am not saying that password vaulting solutions and vendors are an embarrassment. The fact that, having had workable authentication standards for this many years and we still have password vaulting is an embarrassment to our profession. It means that identity vendors have not done enough to enable service providers. It means that service providers still exist who do not want to operate in the best interest of their enterprise customers. At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.) The existence of password vaulting means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands.
- #72 OAuth A4C is simply not a fruitful activity
- #73 OAuth A4C is simply not a fruitful activity
- #74 Second, the fact that password vaulting exists at this point in history is an embarrassment. To be clear, I am not saying that password vaulting solutions and vendors are an embarrassment.
- #77 The fact that, having had workable authentication standards for this many years and we still have password vaulting is an embarrassment to our profession. It means that identity vendors have not done enough to enable service providers. It means that service providers still exist who do not want to operate in the best interest of their enterprise customers. At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.) The existence of password vaulting means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands.
- #79 t means that identity vendors have not done enough to enable service providers.
- #80 It means that service providers still exist who do not want to operate in the best interest of their enterprise customers.
- #81 At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.) The existence of password vaulting means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands.
- #83 We need organizations to be louder in their demands. Image courtesy of Joe Mills: https://www.flickr.com/photos/joedm/2255363378
- #85 I know a little something about killing off bits of IAM… I know we are all trying to kill the password but I think a more reasonable, more achievable, and more effective goal is to eliminate the need for password vaulting through the use of authentication and federated SSO standards. By 2020, if I am still saying this, we have failed.
- #89 By 2017, if I am still saying this, we have failed.
- #90 The authentication wheel is round Image courtesy of Craig Sunter https://www.flickr.com/photos/16210667@N02/12013320215
- #92 Authorization’s wheel is not round in an interesting way
- #94 XACML can do anything; it really is an amazing standard. But the problem with things that allow you to do anything is that they tend to make it hard to do something. The JSON binding is a great start to make XACML more relevant for the modern web. One challenge exists as to how to represent the output of an authorization decision. Once a decision is made, how does the result get communicated to various enforcement points along the way? Certainly OAuth and scopes can be used for that. But this requires an understand of the semantics of scopes, which isn’t a bad thing but it is a thing… service providers have to invest time to understand that. Also there are those who believe bearer tokens are hellspawn… so there’s that too.
- #100 The JSON binding is a great start to make XACML more relevant for the modern web.
- #101 We might be able to employ OAuth and scopes.
- #102 Could be used to represent the output of an authZ decision
- #103 But this requires an understanding of the semantics of scopes, which isn’t a bad thing but it is a thing… service providers have to invest time to understand that.
- #104 What about UMA? It definitely holds promise, especially when we consider the duties of all the parties involved in managing and enforcement access to resources. I really like the idea of a standard that has a profile that describes duties of the actors separate from the wireline protocol description. UMA definitely needs more miles on the road and to be perfectly honest I still have a hard time understanding it in an enterprise context. Maybe now that Eve is coming back to the product world, the community will get more UMA awesomeness.
- #108 There is another thing to think about as we study the roundness of the authorization wheel. Knowing that the load we will have to carry is a heavy one and one that includes “things” I think we need to think about how those “things” can make decisions with more autonomy. How can our authorization systems make authorization decision closer to the place of use at the time of use? As I have been thinking about identity relationship management, I’ve been sketching some design constraints, some laws. This is the law of relationships – Actionable. How can we make relationships actionable so that a thing, an agent, a whatever, can act on the existence of a relationship without always having to consult a back-end authorization service? (use slides from IRM deck)
- #111 Relationships must be able to carry authorization data
- #114 Relationships must be able to carry authorization data to account for situations when the backend service cannot be reached
- #115 Relationships must be able to carry authorization data to account for situations when the backend service cannot be reached
- #116 Authorization’s wheel is not round… in an interesting way Image courtesy of Judith Doyle https://www.flickr.com/photos/doyland/6688993219
- #117 The wheel of attributes is more round than not. Now, this is not a diatribe against commas and their sad magic. There are two parts to the attribute story: access and representation. We can access attributes… sorta. There’s no clear winner that is optimized for the modern web. We’ve got graph APIs, ADAP, and UserInfo Endpoints – not to mention proprietary APIs as well. Notice I added the constraint of “optimized for the modern web.” If remove that constraint, then we could say that access to attributes is a fully solved problem: LDAP. But we are going to a protocol that enables workers in the modern web to access attributes. As for a standardized representation… we have one. Name-value pairs. In fact, name-value pairs might be the new comma. (Ian speaks into cellphone “Siri, remind me to kill name-value pairs next year.) And although NVP are ubiquitous, we don’t have a standard schema. What is the inetOrgPerson of a new generation? There is no inetOrgPerson for millennial developers to use. But does that even matter? We could take SCIM’s schema and decree it to be the standard. But we all know, that each of us would extend the hell out of it. Yes we started with a standard schema, but every service provider’s schema is nearly unique.
- #118 Attributes’ wheel is more round than not
- #119 This won’t be a diatribe against the sad magic of commas. I promise.
- #121 We can access attributes… sorta.
- #122 There’s no clear winner that is optimized for the modern web. We’ve got graph APIs, ADAP, and UserInfo Endpoints – not to mention proprietary APIs as well.
- #124 If remove that constraint, then we could say that access to attributes is a fully solved problem: LDAP. But we are going to a protocol that enables workers in the modern web to access attributes.
- #125 But we are going to a protocol that enables workers in the modern web to access attributes.
- #126 As for a standardized representation… we have one. Name-value pairs. In fact, name-value pairs might be the new comma. (Ian speaks into cellphone “Siri, remind me to kill name-value pairs next year.) And although NVP are ubiquitous, we don’t have a standard schema. What is the inetOrgPerson of a new generation? There is no inetOrgPerson for millennial developers to use. But does that even matter? We could take SCIM’s schema and decree it to be the standard. But we all know, that each of us would extend the hell out of it. Yes we started with a standard schema, but every service provider’s schema is nearly unique.
- #128 In fact, name-value pairs might be the new comma. (Ian speaks into cellphone “Siri, remind me to kill name-value pairs next year.)
- #134 We could take SCIM’s schema and decree it to be the standard. But we all know, that each of us would extend the hell out of it. Yes we started with a standard schema, but every service provider’s schema is nearly unique.
- #136 Attributes’ wheel is roundish
- #137 User provisioning is on the verge to being semi-inflated. Let’s face it the wheel that SPML v2 built was not round. The example that the standard provided wasn’t even valid XML – not an auspicious start. In fact, SPML was a set away from roundness when we think about DSML v2. DSML v2 was a round wheel. It wouldn’t be very useful to day but it would roll. So what about SCIM? I’m bullish on it. Some really smart people worked on it, including my boss. We are supporting it. We hope you support it too. In fact, hopefully, at the end of this week it might just get ratified at the IETF meeting in Toronto. SCIM definitely needs more miles on the road, but I believe that the use cases that have been used to form SCIM are fairly representative of a majority of use cases we have. It can’t do everything but better believe it can do something. And this narrow focus is important as we think about the work we must do. As we as an industry shift from just dealing with employee identities to those of customers, citizens, and things, there is shift from heavy rich user provisioning to lighter weight registration and profile management. SCIM is just as applicable in an employee identity scenario as it is in a customer identity scenario. And thus is well positioned to make the transition.
- #138 User Provisioning’s wheel is nearly roundish.
- #139 Let’s face it the wheel that SPML v2 built was not round. The example that the standard provided wasn’t even valid XML – not an auspicious start. In fact, SPML was a step away from roundness when we think about DSML v2. DSML v2 was a round wheel. It wouldn’t be very useful to day but it would roll.
- #143 So what about SCIM? I’m bullish on it. Holds great promise. Some really smart people worked on it, including my boss. We are supporting it. We hope you support it too. In fact, hopefully, at the end of this week it might just get ratified at the IETF meeting in Toronto. SCIM definitely needs more miles on the road, but I believe that the use cases that have been used to form SCIM are fairly representative of a majority of use cases we have. It can’t do everything but better believe it can do something. And this narrow focus is important as we think about the work we must do. As we as an industry shift from just dealing with employee identities to those of customers, citizens, and things, there is shift from heavy rich user provisioning to lighter weight registration and profile management. SCIM is just as applicable in an employee identity scenario as it is in a customer identity scenario. And thus is well positioned to make the transition.
- #150 As we as an industry shift from just dealing with employee identities to those of customers, citizens, and things, there is shift from heavy rich user provisioning to lighter weight registration and profile management. SCIM is just as applicable in an employee identity scenario as it is in a customer identity scenario. And thus is well positioned to make the transition.
- #154 User provisioning’s wheel is nearly roundish
- #157 A question – how do you discover identity services of from a service provider? I don’t mean in a specific ODIC way, but in a more general way. How do you know if they use SAML, SCIM, a proprietary attribute API, FIDO U2F, etc? Is there a way to kickstart point-to-point identity relationships without paying the cost of point-to-point drudgery? Could I point my identity system at yours, form a relationship between the organizations, and start to use our joint identity services to meaningfully interact? Let me ask this a different way – do we have hubs and axels for our roundish wheels? Can we building something that removes the heavy lifting when offering and/or consuming identity services? I believe this is the uncharted standards territory into which we must blaze a trail.
- #158 A question – how do you discover identity services of from a service provider? I don’t mean in a specific ODIC way, but in a more general way. How do you know if they use SAML, SCIM, a proprietary attribute API, FIDO U2F, etc? Is there a way to kickstart point-to-point identity relationships without paying the cost of point-to-point drudgery? Could I point my identity system at yours, form a relationship between the organizations, and start to use our joint identity services to meaningfully interact? Let me ask this a different way – do we have hubs and axels for our roundish wheels? Can we building something that removes the heavy lifting when offering and/or consuming identity services? I believe this is the uncharted standards territory into which we must blaze a trail.
- #163 Can we kickstart point-to-point identity relationships without paying the p2p costs?
- #165 Can we build something that removes the heavy lifting when offering and/or consuming identity services?
- #167 That modern era is one in which more people and more things are more closely related. It is an era that holds the promise of “identity as business enabler.” And in this modern era identity will not only deliver the right access to the right people at the right time but the right experience to the right people at the right time. Not just people but things too To be fair, this modern era will require us to haul a heavy load. To do that we need round wheels. We need workable identity standards. We have made great progress but we are not there yet. I’ll ask 3 things of this audience and of our industry. First, adopt standards. If you aren’t using identity standards, you are inventing your own wheel. That is a strategy only optimized for the short-run. If the current ones don’t work for you, bring those use cases to standards bodies. If you don’t know where to go, ping me, or Mark, or Eve, we’ll help you. Second, help others adopt standards. Build SDKs to help people use OpenID and SAML. Support open source implementations of SCIM and OAuth. Start at home – with you organization’s developers and move out from there. Third, demand standards. From your identity technology providers. Demand standards. From your business service providers. Demand standards. From your own development teams. Demand standards. If for no other reason than to kill off the need for password vaulting. Demand standards. Lastly, keep in mind that a round wheel is not an end in and of itself. A great spec is potentially satisfying to the hard-core identity dorks in the room, me included, but that isn’t the real goal. We reinvent the wheel, we revisiting and rebuild our standards to get round ones – beautifully functioning ones that help carry the loads we must shoulder and us get to where we need to go in this era of modern identity.
- #170 It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- #171 It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- #172 It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- #173 It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- #176 As we continue to refine our standards, we need a way of evaluating the roundness of those wheels, so to speak. We need some set of design considerations to help use decided whether a standard will get us from here to there. A few weeks ago I debuted the laws of relationships. They a set of considerations that we as identity professionals must be mindful of as we begin to navigate the waters of modern IAM – of identity relationship management. They can help evaluate the roundness of our standards… but only if you lend a hand. Kantara is creating an Identity Relationship Management working group to which I am giving these Laws of Relationships. I hope you will join me, and Joni, and Allan, and others in this new working group to help make identity ready for the modern era.
- #179 Kantara is creating an Identity Relationship Management working group to which I am giving these Laws of Relationships.
- #180 I hope you will join me, and Joni, and Allan, and others in this new working group to help make identity ready for the modern era.
- #185 If you don’t know where to go, ping me, or Mark, or Eve, we’ll help you.
- #200 Lastly, keep in mind that a round wheel is not an end in and of itself. A great spec is potentially satisfying to the hard-core identity dorks in the room, me included, but that isn’t the real goal. We reinvent the wheel, we revisiting and rebuild our standards to get round ones – beautifully functioning ones that help carry the loads we must shoulder and us get to where we need to go in this era of modern identity.
- #202 at least to the hard core identity geeks in the room