tag:blogger.com,1999:blog-124470722024-03-07T13:54:59.373-05:00ConnectIDWhen you don't have anything nice to say, well then perhaps its time consider a career as an analyst.Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.comBlogger1979125tag:blogger.com,1999:blog-12447072.post-79794169670706423792015-07-28T13:32:00.003-04:002015-07-28T13:37:43.758-04:00NAPPS has left the building (but is still on the front lawn) A good standards effort defines specifications that build on the
existing stack of underlying protocols, cryptographic techniques, data
formats and platform capabilities. A better standards effort defines
specifications that can adapt accordingly as that existing stack changes
and evolves. The very best standards efforts know when to announce
victory, pack their bags, and go home when that stack evolves in such a
way to mitigate the value of the standard in the first place.<br />
<br />
By this measure, NAPPS, the OIDF WG
chartered to define mechanisms in support of an SSO experience for
native applications, is an awesome standards effort.<br />
<br />
As has been previously pointed out by <a href="https://www.pingidentity.com/en/blog/2015/07/01/bringing_single_sign-on_to_mobile_applications.html">John Bradley</a> and <a href="https://www.pingidentity.com/en/blog/2015/06/19/mobile_os_developments_native_application_authentication.html">myself</a>,
the mobile OSs are evolving their support for native SSO, both iOS and
Android are adding new features that make SSO possible 'out of the box',
without the introduction of specialized application software on the
device, as the NAPPS group had been proposing. Consequently, the value
of the 'Token Agent' model that NAPPS was proposing and standardizing is
diminished - fundamentally we don't need to supplement the mobile OSs
to achieve native SSO when they provide sufficient capabilities on their
own.<br />
<br />
Consequently, as John writes, the NAPPS WG is 'pivoting' and, rather
than delivering a normative specification for the Token Agent role, will
instead:<br />
<br />
<div class="tab" style="margin-left: 30px;">
<em>"...document best
practices for Single Sign-on for Enterprise and Software as a Service
Providers using these new features in combination with the PKCE
specification, as well as filling in any remaining gaps to allow SaaS
providers to fully support OAuth and OpenID Connect enabled native
applications in a secure way without forcing users into extra
unproductive logins."</em></div>
<div class="tab" style="margin-left: 30px;">
<em><br /></em></div>
<img align="right" alt="NAPPS_blog.png" class="mt-image-none" height="318" src="https://www.pingidentity.com/content/dam/pic/images/managed/NAPPS_blog.png" style="padding-left: 15px;" width="212" /><br />
In addition to these sort of guidelines, there is discussion about
the development of open source SDKs that would wrap up all these
features and flows - simplifying for application developers how to hook
into this native SSO model. Discussions are underway as to where
development of these libraries make sense.<br />
Interestingly, while the value of a Token Agent has been marginalized
by the new mobile OS features for the native SSO use case, the TA model
may yet find a home in the Internet of Things.<br />
<br />
Many IoT devices are characterized by limited UI capabilities for
display and user input - both of which are critical for the initial
binding of the device to a user account and corresponding provisioning
of credentials. But if Things are constrained in this way, mobile
devices aren't - and so can facilitate this initial setup step.<br />
<br />
Shown here is a scenario where a native application on a device plays
the role of a Token Agent on behalf of a Thing. The TA obtains an OAuth
access token for the Thing and then delivers that token using some
short range wireless protocol such as BLE or NFC. Once the Thing has its
token, it can use that to authenticate itself when interacting with
cloud endpoints or even other Things.<br />
<br />
<br />
Should the TA model be eventually applied to IoT use cases, perhaps
my not insignificant $$ investment in a large supply of 'There is
nothing token about my agent' t-shirts will not be wasted. Let us hope.Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-63745197299808005652015-03-26T16:22:00.000-04:002015-03-26T16:24:03.987-04:00NAPPS - a rainbow of flavours<div class="separator" style="clear: both; text-align: left;">
Below is an arguably unnecessarily vibrant swimlane of the proposed (Native Appplications) NAPPS flow for an enterprise built native application calling an on-prem API.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The very bottom arrow of the flow (that from Ent_App to Ent_RS) is the actual API call that, if successful will return the business data back to the native app. That call is what we are trying to enable (with all the rainbow hued exchanges above)</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
As per normal OAuth, the native application authenticates to the RS/API by including an access token (AT). Also show is the possibility of the native application demonstrating proof of possession for that token but I'll not touch on that here other than to say the corresponding spec work is underway).</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
What differs in a NAPPS flow is how the native application obtains that access token. Rather than the app itself taking the user through an authentication & authorization flow (typically via the system browser), the app gets its access token via the efforts of an on-device 'Token Agent' (TA). </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Rather than requesting an access token of a network Authorization Service (as in OAuth or Connect), the app logically makes its request of the TA - as labelled below as 'code Request + PKSE'. Upon receiving such a request from an app, the TA will endeavour to obtain from the Ent_AS an access token for the native app. This step is shown in green below. The TA uses a token it had previously obtained from the AS in order to obtain a new token for the app. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
In fact, what the TA obtains is not the access token itself, but an identity token (as defined by Connect) that can be exchanged by the app for the more fundamental access token - as shown in pink below. While this may seem like an unnecessary step, it actually</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<ol>
<li>mirrors how normal OAuth works, in which the native app obtains an authz code and then exchanges that for the access token (this having some desirable security characteristics)</li>
<li>allows the same pattern to be used for a SaaS app, ie one whether there is another AS in the mix and we need a means to federate identities across the policy domains. </li>
</ol>
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq1gP8AWbBHk8ryedJB8bbk7JGWP0_UNho_VWPoNqFFo6oq0ZC2zgA_pnaI6WkrJf2kOp0UWCHo3EVT2k-T-R-hMRbEgpV8xIT-t24HX-ZHYyUjns9tnz6_FKSvRuzaMWmnbNTYw/s1600/Screen+Shot+2015-03-26+at+4.02.49+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq1gP8AWbBHk8ryedJB8bbk7JGWP0_UNho_VWPoNqFFo6oq0ZC2zgA_pnaI6WkrJf2kOp0UWCHo3EVT2k-T-R-hMRbEgpV8xIT-t24HX-ZHYyUjns9tnz6_FKSvRuzaMWmnbNTYw/s1600/Screen+Shot+2015-03-26+at+4.02.49+PM.png" height="302" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
When I previously wrote 'TA uses a token it had previously obtained from the AS', I was referring to the flow coloured in light blue above. This is a pretty generic OAuth flow , the only novelty is the introduction of the PKSE mechanism to protect against a malicious app stealing tokens by sitting on the app's custom URL scheme.</div>
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-63097904510741358972014-11-07T11:33:00.002-05:002014-11-07T11:33:41.693-05:00Application unbundling & Native SSOYou used to have a single application on your phone from a single social provider, you likely now have multiple.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-Qh0p8qVG1rA/VFzK8vFwjhI/AAAAAAAAOcM/1WBBfI70NEk/s1600/Screen%2BShot%2B2014-11-07%2Bat%2B8.36.10%2BAM.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://2.bp.blogspot.com/-Qh0p8qVG1rA/VFzK8vFwjhI/AAAAAAAAOcM/1WBBfI70NEk/s1600/Screen%2BShot%2B2014-11-07%2Bat%2B8.36.10%2BAM.png" height="174" width="320" /></a></div>
Where the was Google Drive, there is now Sheets, Docs, and Slides - each individual application optimized for a particular document format.<br />
<br />
Where the chat function used to be a tab within the larger Facebook application , there is now Facebook Messenger - a dedicated chat app.<br />
<br />
LinkedIn has 4 individual applications.<br />
<br />
The dynamic is not unique to social applications.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-49y_GaOZEAg/VFzS6pJfzaI/AAAAAAAAOcw/Q9QKIrh16vE/s1600/Screen%2BShot%2B2014-11-07%2Bat%2B9.09.29%2BAM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-49y_GaOZEAg/VFzS6pJfzaI/AAAAAAAAOcw/Q9QKIrh16vE/s1600/Screen%2BShot%2B2014-11-07%2Bat%2B9.09.29%2BAM.png" height="194" width="320" /></a></div>
<br />
<br />
According to <a href="https://medium.com/@dannysauter/5-observations-on-mobile-app-unbundling-6d57fdd1ad83">this</a> article<br />
<blockquote class="tr_bq">
<em class="markup--em markup--p-em">Mobile app unbundling occurs when a
feature or concept that was previously a small piece of a larger app is
spun off on it’s own with the intention of creating a better product
experience for both the original app and the new stand-alone app</em>.</blockquote>
The unbundling trend seems mostly driven by the constraints of mobile devices - multiple functions hidden behind tabs may work on a desktop browser, but on a small screen, they may be hidden and only accessible through scrolling or clicking.<br />
<br />
That was the <a href="http://www.theverge.com/2014/11/6/7170791/mark-zuckerberg-finally-explains-why-he-forced-you-to-download-the">stated justification</a> for Facebook's unbundling of Messenger<br />
<blockquote class="tr_bq">
<i>We wanted to do this because we believe that this is a better
experience. Messaging is becoming increasingly important. On mobile,
each app can only focus on doing one thing well, we think. The primary purpose of the Facebook app is News Feed. Messaging was
this behavior people were doing more and more. 10 billion messages are
sent per day, but in order to get to it you had to wait for the app to
load and go to a separate tab. We saw that the top messaging apps people
were using were their own app. These apps that are fast and just
focused on messaging. You're probably messaging people 15 times per day.
Having to go into an app and take a bunch of steps to get to messaging
is a lot of friction.</i></blockquote>
Of course, unbundling clearly isn't for everybody ....<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-P2aMdA_9Hj8/VFzQUgDSAvI/AAAAAAAAOck/I0_LGWPy14k/s1600/Screen%2BShot%2B2014-11-07%2Bat%2B8.59.28%2BAM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="http://4.bp.blogspot.com/-P2aMdA_9Hj8/VFzQUgDSAvI/AAAAAAAAOck/I0_LGWPy14k/s1600/Screen%2BShot%2B2014-11-07%2Bat%2B8.59.28%2BAM.png" height="320" width="188" /></a></div>
<br />
<br />
I can't help but think about unbundling from an identity angle. Do the math - if you break a single application up into multiple applications, then what was a single authentication & authorization step becomes multiple such steps. And, barring some sort of integration between the unbundled applications (where one application could leverage a 'session' established for another) this would mean the user having to explicitly login to each and every one of those applications.<br />
<br />
The premise of 'one application could leverage a session established for another' is exactly that which the <a href="http://openid.net/wg/napps/">Native Applications (NAPPS) WG</a> in the OpenID Foundation is enabling in a standardized manner. NAPPS is defining both 1) an extension and profile of OpenID Connect by which one native application (or the mobile OS) can request a security token for some other native application 2) mechanisms by which the individual native applications can request and return such tokens.<br />
<br />
Consequently, NAPPS can mitigate (at least one of) the negative implications of unbundling.<br />
<br />
The logical end-state of the trend towards making applications 'smaller' would appear to be applications that are fully <i>invisible</i>, ie those that the user doesn't typically launch by clicking on an icon, but rather receives interactive <a href="http://www.wutwut.com/">notifications</a> & prompts only when relevant (as determined by the application's algorithm). What might the implications of such invisible applications be for identity UX?<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-33377300883171748862014-11-05T13:51:00.002-05:002014-11-05T13:51:53.320-05:00Sticky Fingers<div class="tr_bq">
<a href="http://4.bp.blogspot.com/-Cls5WBvaaBo/VFpGocVVzNI/AAAAAAAAObk/qXfuTe0g1Cc/s1600/Screen%2BShot%2B2014-11-05%2Bat%2B10.47.23%2BAM.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://4.bp.blogspot.com/-Cls5WBvaaBo/VFpGocVVzNI/AAAAAAAAObk/qXfuTe0g1Cc/s1600/Screen%2BShot%2B2014-11-05%2Bat%2B10.47.23%2BAM.png" height="80" width="200" /></a><a href="https://www.digits.com/">Digits</a> is a new phone-number based login system from Twitter.</div>
<blockquote class="tr_bq">
<span style="background-color: #f6f7fb; color: #292f33; font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 15px; text-align: center;">Digits is a simple, safe way of using your phone number to sign in to your favorite apps.</span></blockquote>
Note that Digits is not just using your <i>phone</i> to sign in (there are a number of existing mobile-based systems), but your <i>phone number. </i><br />
<br />
Digits is an SMS-based log in system (unlike mobile OTP systems like Google Authenticator). When trying to login to some service, the user supplies their phone number, at which they soon receives an SMS, this SMS carrying a one-time code to be entered into the login screen. After Twitter's service validates the code, the application can be (somewhat) confident that the user is the authorized owner of that phone number.<br />
<br />
Now, the above makes it clear that Digits relies on only a single factor, ie a 'what you have' of the phone associated with the given phone number. This <a href="https://blog.twitter.com/2014/a-better-way-to-sign-in-with-digits">post</a> even brags that you need not worry about any additional account names or passwords. But that same post claims that Digits is actually more than a single factor<br />
<blockquote class="tr_bq">
<i>Digits.com, an easy way for your users to manage their Digits accounts and enable two-factor authentication</i></blockquote>
As much as I squint, I can see no other factor in the mix. (And it sure isn't the phone number.)<br />
<br />
Digits apparently also has privacy advantages.<br />
<blockquote class="tr_bq">
<i>Digits won't post on your behalf, so what you say and where you say it is completely up to you</i></blockquote>
Well, to be precise, Digits <b>can't</b> post on your behalf ... And is it not somewhat ironic that Twitter touts as an advantage of Digits the fact that it is not hooked into your Twitter account??<br />
<br />
Presumably this is presented in contrast to the existing '<a href="https://dev.twitter.com/web/sign-in">Sign-in with Twitter'</a> system, use of which can allow a user to authorize applications to post to Twitter on their behalf (as the system is based on OAuth 1.0).<br />
<br />
But of course, 'Sign-in with Twitter' allows applications to post on behalf of users only because Twitter made the business decision to make this permission part of the default set of authorizations. Twitter could have chosen to make their consent more granular and tightened up the default.<br />
<br />
Dick Hardt <a href="https://medium.com/@dickhardt/the-digital-identifier-to-rule-them-all-b94d6ce68e46">analyzed</a> Digits and hilited two fundamental issues of using phone numbers as identifier<br />
<br />
<br />
<ol>
<li>the privacy risk associated with a user presenting the same identifier to all applications (as it enables subsequent correlation amongst those applications without the user's consent). It's pretty trivial to spin up new email addresses (even disposable ones) to segment your online interactions and prevent correlation. Is that viable for phone numbers?</li>
<li>that applications generally aren't satisfied with only knowing that <i>who</i> a particular user is, but almost always want to know the <i>what</i> as well, ie their other identity attributes, social streams etc</li>
</ol>
<br />
Dick, having made the second point, perversely then conjectures that it may not be an issue<br />
<blockquote class="tr_bq">
<i>as mobile apps replace desktop web sites, the profile data may not be as relevant as it was a decade ago</i></blockquote>
I can't imagine why the native vs browser model would impact something as fundamental as wanting to understand your customer? <br />
<br />
Twitter actually tries to position this limitation as a strength of Digits<br />
<blockquote class="tr_bq">
<i>Each developer is in control with Digits. It lets you build your own
profiles and apps, giving you the security of knowing your users are
SMS-verified. </i></blockquote>
The motivation for Digits.com becomes a bit clearer when you <a href="https://blog.twitter.com/2014/a-better-way-to-sign-in-with-digits">read more</a><br />
<blockquote class="tr_bq">
<i>We built Digits after doing extensive research around the world about
how people use their smartphones. What we found was that first-time
Internet users in places like Jakarta, Mumbai and São Paulo were
primarily using a phone number to identify themselves to their friends.</i></blockquote>
Twitter must have looked at their share in these markets and determined they needed a different way to mediate user's application interactions.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-IQUzyf5s2Hw/VFpqWpRcLNI/AAAAAAAAOb8/mu9YuNCu7U8/s1600/Screen%2BShot%2B2014-11-05%2Bat%2B1.19.29%2BPM.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://3.bp.blogspot.com/-IQUzyf5s2Hw/VFpqWpRcLNI/AAAAAAAAOb8/mu9YuNCu7U8/s1600/Screen%2BShot%2B2014-11-05%2Bat%2B1.19.29%2BPM.png" height="266" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Source - http://stats.areppim.com/stats/stats_socmediaxtime_afr.htm</td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-33023488850146573432014-10-28T16:39:00.002-04:002014-10-28T16:39:49.765-04:00Less is moreI attended GigaOM's Structure Connect conference in San Francisco last week. The event was great, lots of interesting discussions & panels.<br />
<br />
I was in a 'Securing the IoT' breakout session where one of the GigaOM analysts made the assertion (paraphrasing)<br />
<blockquote class="tr_bq">
Developers need better training on security, they need to take more responsibility for securing their applications.</blockquote>
This actually runs completely counter to what I've been seeing as the overarching trend around application security, namely that developers need to take (or even be given) <i>less</i> responsibility for securing their applications - not more.<br />
<br />
If their app has to handle $$, do developers directly track currency exchange rates? No, they find an API that does that and so removes them from a task secondary to that of the application itself. The currency API abstracts away from the developer all the messiness - they make a simple REST call and get back a tidy bit of JSON to parse & use.<br />
<br />
From the developers point of view, why would security be different? Do they want to deal with the specific details of supporting different authentication protocols, crypto etc. Or would they prefer to focus on adding features and functionality to their apps?<br />
<br />
The trend towards lightening the security load for developers manifests in various ways<br />
<br />
<ul>
<li>Social 'Login with X' SDKs - the large social providers make it as easy as they can for native application developers to hook into their identities. For instance, <a href="https://developers.facebook.com/docs/facebook-login/ios/v2.1">Facebook Login</a> promises</li>
</ul>
<blockquote class="tr_bq">
<span style="background-color: white; color: #4e5665; font-size: 14px; line-height: 20px;"><span style="font-family: Courier New, Courier, monospace;">The Facebook SDK for iOS provides various login experiences that your app can use to authenticate someone. This document includes all the information you need to know in order to implement Facebook login in your iOS app.</span></span></blockquote>
<blockquote class="tr_bq">
<span style="background-color: white; color: #4e5665; font-family: 'helvetica neue', helvetica, arial, 'lucida grande', sans-serif; font-size: 14px; line-height: 20px;">Google has the comparable the Google+ Sign-In, the documentation for which asserts</span></blockquote>
<blockquote class="tr_bq" style="background-color: white; border: 0px; color: #222222; line-height: 22.3999996185303px; margin-bottom: 1.5em; padding: 0px; vertical-align: baseline;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><span style="background-color: white; color: #333333; line-height: 1.3;"><b>Avoid the hassle of creating your own authentication system</b></span>Google+ Sign-In mitigates data-breach risks and reduces the burden and costs of identity security. The Google authentication window creates a trusted link between you, your users, and their Google account.</span></blockquote>
<br />
<br />
<ul>
<li>REST gateways - many enterprise REST APIs are fronted by a gateway that intercepts incoming calls from clients and applies processing before delivering the call on to the actual API. The API developer need not directly deal with the authentication tokens attached to the original call, insulated from that burden by the gateway. Instead the gateway </li>
</ul>
<ul>
<li>IDaaS - or Identity as a Service, is the trend of enterprises moving out to the Cloud certain identity & authentication mechanisms (just like many other enterprise functions are being outsourced). Rather than directly dealing with user provisioning, federation, or password vaulting etc the enterprise subscribes to the services of an IDaaS provider. The IDaaS takes on the full burden of the complexity of dealing with multiple protocols, business partners, customers, SaaS etc and offers back to the enterprise developer a much simpler integration proposition.</li>
</ul>
<div>
The above are all examples of freeing application developers from having to bear full responsibility for securing APIs & native applications. And last I checked, both will be relevant for the Internet of Things. Freed from the burden of security, IoT developers will be able to focus their attention where they should - namely creating new & interesting visual paradigms for my wearable step data.</div>
<br />
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-79311578821440276752014-10-08T12:33:00.004-04:002014-10-08T12:33:45.926-04:00Social Media 2 Factor authentication<div dir="ltr" id="docs-internal-guid-418fe607-f097-87d3-b29d-15b9c32e83be" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<br /></div>
<span style="font-family: 'Trebuchet MS'; font-size: 21px; line-height: 1.15;">Premise</span><br />
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">A user can authenticate to a web application (or a federation server) by sending an update (tweet, Facebook update, etc) with a randomly generated hashtag previously delivered to the user in the login interface. </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">The fundamental requirement is that </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
</div>
<ol>
<li><span style="font-family: Arial; font-size: 15px; line-height: 1.15;">the user be able to demonstrate ownership of the social account previously connected to their account at the authentication server by including a challenge string in a tweet, update etc</span></li>
<li><span style="font-family: Arial; font-size: 15px; line-height: 1.15;">the authentication server be able to determine that a particular challenge string was added to a tweet, update etc associated with a particular social account </span></li>
</ol>
<br />
<h1 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="font-family: 'Trebuchet MS'; font-size: 21px; font-weight: normal; vertical-align: baseline;">User Experience</span></h1>
<br />
<h3 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 8pt;">
<span style="color: #666666; font-family: 'Trebuchet MS'; font-size: 16px; vertical-align: baseline;">Step 1 : </span></h3>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">User binds their social account to the authentication server</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><img alt="Screen Shot 2014-05-22 at 3.12.58 PM.png" height="241px;" src="https://lh6.googleusercontent.com/lpYQ4Gv-sjyqcrC5sKneaW8PeblKDPhsXlwr3OKCooa6Dh8oXMQytgqATkf4Xi7Qq_1x_9P4B-X1Cl2XmpaCQKMhRZhkb-d_Dqg5n_bFRTUb5xsKh6QPfaLCHga1wP1NWw" style="-webkit-transform: rotate(0.00rad); border: none; transform: rotate(0.00rad);" width="389px;" /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Alternatively, the ‘binding’ could consist solely of the user telling the authentication server their Twitter handle. </span></div>
<h3 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 8pt;">
<span style="color: #666666; font-family: 'Trebuchet MS'; font-size: 16px; vertical-align: baseline;">Step 2: </span></h3>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Later, User visits login page</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">User logs in with first factor, ie password, or SSO</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Login UI displays randomly generated challenge string</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><img alt="Screen Shot 2014-05-22 at 3.33.01 PM.png" height="137px;" src="https://lh6.googleusercontent.com/WmdLWWCKEu42Qt9nOCbb36UOLun6oLrvnkcf9ylqtKzzroO3XxKisked4X_-FxkAY8yezb3AjHr0pFHzVZO0LeJH7Xbo3rPc9Ev2ok5LAMurlPI1MalJnu_hY8qIl9ekBw" style="-webkit-transform: rotate(0rad); border: none; transform: rotate(0rad);" title="" width="156px;" /></span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Authentication server stores away challenge string against that user’s account</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Alternatively, the challenge mechanism could be via Twitter, ie the authentication server sends the user a tweet, and the User response would be a RT.</span></div>
<br />
<h3 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 8pt;">
<span style="color: #666666; font-family: 'Trebuchet MS'; font-size: 16px; vertical-align: baseline;">Step 3: </span></h3>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">User sends tweet , including challenge hashtag from Step 2</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><img alt="Screen Shot 2014-05-22 at 3.35.27 PM.png" height="221px;" src="https://lh5.googleusercontent.com/ysJFBBlU9Z1oIne71QfMSfUpkhf9k2YLtKaECbxJB6D7XUzQlmt62zlm96kFXpB2czFH9p41sOI0xZed1Sn-GuaQi8b-WCebNGpqQ_BJk06l0ijR464aPrWGMYbjDqLT6Q" style="-webkit-transform: rotate(0.00rad); border: none; transform: rotate(0.00rad);" width="511px;" /></span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">The response format & channel will depend on the nature of the challenge and how the user’s social media account were bound to the account at the authentication server. </span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Step 4: </span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">After displaying the hashtag challenge to the user , the authentication server polls the user’s tweet stream (or equivalent) on some schedule for a tweet (or post) containing the challenge hashtag.</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">If such a tweet is found within some time period, the authentication page displays successful login.</span></div>
<h1 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="font-family: 'Trebuchet MS'; font-size: 21px; font-weight: normal; vertical-align: baseline;">Discussion</span></h1>
<br />
<ol style="margin-bottom: 0pt; margin-top: 0pt;">
<li dir="ltr" style="font-family: Arial; font-size: 15px; list-style-type: decimal; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 15px; vertical-align: baseline;">The default would be for the user to manually type the challenge string into their tweet. Might it be possible for the authentication server to instead/also display a QR code, for the user to scan and so launch their mobile Twitter client with the tweet ready to send?</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 15px; list-style-type: decimal; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 15px; vertical-align: baseline;">Instead of a string, the challenge could consist of a link to a specific picture or some other media</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 15px; list-style-type: decimal; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 15px; line-height: 1.15;">If the user has previously authorized other applications to be able to send tweets on their behalf, then those other applications would potentially be able to send a response tweet, but only if they were able to know the challenge. Consequently, the authentication model is likely only relevant for a 2nd factor, as having the user first authenticated with the other factor would prevent other applications from knowing the challenge string.</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 15px; list-style-type: decimal; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 15px; line-height: 1.15;">if the authentication server were able to determine how many applications the user has granted the ability to tweet on their behalf, then conceivably it could factor that into it’s assessment of assurance</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 15px; list-style-type: decimal; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 15px; line-height: 1.15;">There could be a viral component to the marketing of the authentication service, as the user’s followers would see the authentication tweets</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 15px; list-style-type: decimal; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 15px; line-height: 1.15;">Is there a risk of violating Twitter ToS?</span></div>
</li>
</ol>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-84256437665837463162014-10-08T10:16:00.001-04:002014-10-08T10:16:23.914-04:00A symmetrical NAPPS model<br />
The NAPPS WG in the OIDF is defining a framework for enabling SSO to native applications.<br />
<br />
One challenge has been in supporting 3rd party native applications from large SaaS that already have an OAuth & token infrastructure (Salesforce as an example).<br />
<br />
For this sort of SaaS, NAPPS has to allow the SaaS's existing OAuth AS to issue the token ultimately used by the app on the API calls.<br />
<br />
The NAPPS spec is evolving to dealing with such applications in almost exactly the same way as it does native applications that call on-prem APIs built by the enterprise.<br />
<br />
Fundamentally, for both categories of native applications, the enterprise AS issues to the Token Agent an identity token JWT, this handed to the application through the mobile OS bindings. The app exchanges this JWT for the desired access token to be used on API calls - the only difference is the AS at which the JWT is exchanged.<br />
<br />
<span style="font-family: Arial;"><b>Local native apps</b></span>
<span style="font-family: Arial;"></span><br />
<ol><span style="font-family: Arial;">
<li>app request<span style="font-family: Arial;">s
tokens of TA, includes generated nonce</span></li>
<li>TA uses its RT to send
request + nonce to AS</li>
<li>AS returns PoP JWT</li>
<li>TA hands over PoP JWT to
app</li>
<li>App exchanges JWT, shows PoP</li>
<li>AS returns token(s) to app</li>
</span></ol>
<span style="font-family: Arial;"><span style="font-family: Arial;"><span style="font-family: Arial;"><span style="font-family: Arial;"><span style="font-family: Arial;"><span style="font-family: Arial;"><span style="font-family: Arial;"><span style="font-family: Arial;">
<span style="font-family: Arial;"><b>3rd party native apps</b></span></span></span></span></span></span></span></span></span><b> </b>
<br />
<ol>
<li><span style="font-family: Arial;">app request</span><span style="font-family: Arial;">s tokens of TA,</span><span style="font-family: Arial;"> includes generated nonce</span></li>
<li>TA uses its RT to send request + nonce to AS1</li>
<li><span style="font-family: Arial;">AS1 returns PoP JWT,
ta</span><span style="font-family: Arial;">rget<span style="font-family: Arial;">ed
at A<span style="font-family: Arial;">S2</span></span></span></li>
<li><span style="font-family: Arial;">TA hands over PoP JWT to app</span></li>
<li><span style="font-family: Arial;">App exchanges PoP JWT against AS2, shows PoP</span></li>
<li><span style="font-family: Arial;">AS2 returns
token</span><span style="font-family: Arial;">(s) to app</span></li>
</ol>
<div>
<span style="font-family: Arial;">Step 5 in the 3rd party sequence implies a federated trust model - the SaaS AS2 must be able to trust & validate the JWT issued by the enterprise AS1.</span></div>
<div>
<span style="font-family: Arial;"><br /></span></div>
<br />
The above model is attractive for the symmetry it provides between both application categories.Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com5tag:blogger.com,1999:blog-12447072.post-38389748333428489912014-10-07T09:08:00.000-04:002014-10-07T09:08:56.689-04:00As long as X is true .....<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt; text-align: left;">
<br />
<span style="font-family: Arial; font-size: 15px; line-height: 1.15;">When my Samsung Gear watch is within BLE range of my Samsung S5, I need not enter my screen unlock pattern in order to get into the phone. The S5 interprets the proximity of the Gear as a proxy for my own proximity, and so deduces that it is myself handling the phone and not somebody else. </span><br />
<span style="font-family: Arial; font-size: 15px; line-height: 1.15;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15;">This is an example of what appears to be an emerging model for authentication, which I’ll give the pretentious name of ‘conditional session persistence’ and characterize as</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial; font-size: 15px; font-weight: bold; vertical-align: baseline;">‘As long as X is true, no need to Y’ </span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">where ‘X’ is some condition - the continued state of which protects the user from having to perform ‘Y’, generally some sort of explicit login operation.</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">For my Gear & S5 use case, the X condition is ‘the Gear is within BLE range of the S5’ and the ‘Y’ is ‘demonstrate knowledge of secret unlock pattern to access phone’.</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">This authentication model is appearing elsewhere.</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<a href="https://lh4.googleusercontent.com/uxIuv1BZ3WzyV0ryOSNdSeDUGyQ6MKVYKSECU-RtqXKxgoUVGERxdbEbEtwN73-o-gGT0aR8VrOUuj-kxg6gpyyZ0BakBwTbTIovEqZsdGlOZOgKCGnJDvR8OjT5gwHI1Q" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="Screen Shot 2014-10-06 at 12.47.17 PM.png" border="0" height="124px;" src="https://lh4.googleusercontent.com/uxIuv1BZ3WzyV0ryOSNdSeDUGyQ6MKVYKSECU-RtqXKxgoUVGERxdbEbEtwN73-o-gGT0aR8VrOUuj-kxg6gpyyZ0BakBwTbTIovEqZsdGlOZOgKCGnJDvR8OjT5gwHI1Q" style="-webkit-transform: rotate(0rad); border: none; transform: rotate(0rad);" width="136px;" /></a><span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">The <a href="http://www.getnymi.com/">Nymi </a>wristband records the user’s ECG and sends it to a companion app on a paired device for it to be compared to the previously recorded ECG pattern. If the biometric comparison is successful, then the companion application responds back to the Nymi that it should unlock a previously registered crypto key and use that key to authenticate to resources and services. To ‘authenticate’ to the Nymi the user must touch a finger of the other hand to the top of the wristband - this creates an electrical loop that allows the ECG to be recorded. Once recorded and successfully compared, the ECG is not measured again, at least not until the wristband is removed from the user’s wrist. As long as the wristband stays on the user’s wrist the Nymi remains willing to assert the user’s identity by presenting the key (or presumably separate keys for different resources). Once removed from the wrist, then the user is required to re-authenticate once more via their ECG. </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">The <a href="https://www.apple.com/ca/watch/">Apple Watch</a> is reported to use the same model. </span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-left: 36pt; margin-top: 0pt;">
<a href="https://lh3.googleusercontent.com/8nhfxmVqkzODLx1FAEIW5_QcD0Am7p2TkYLRUgDbE70t-ANN13jtOBmLqocVY-oaOPfWJHQhWpjWVIEeFDan70Oyks1d5w_FgDWswOJfLs5R8KpGVrMKIrd6m7s7DhjpBA" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Screen Shot 2014-10-06 at 12.03.26 PM.png" border="0" height="176px;" src="https://lh3.googleusercontent.com/8nhfxmVqkzODLx1FAEIW5_QcD0Am7p2TkYLRUgDbE70t-ANN13jtOBmLqocVY-oaOPfWJHQhWpjWVIEeFDan70Oyks1d5w_FgDWswOJfLs5R8KpGVrMKIrd6m7s7DhjpBA" style="-webkit-transform: rotate(0rad); border: none; transform: rotate(0rad);" width="178px;" /></a><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline;">On the back of the case, a ceramic cover with sapphire lenses</span><span style="font-family: Arial; font-size: 9px; font-style: italic; vertical-align: super;">1</span><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline;"> protects a specially designed sensor that uses infrared and visible-light LEDs and photodiodes to detect your heart rate.</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Via the 4 sensors on the back, the Watch will be able to determine when it is removed from the wrist after an initial authentication (by PIN it seems but it’s not inconceivable that it uses the heart rate as a biometric?). As long as the Watch stays on the user’s wrist the original authentication remains valid and the Watch can be used to, for instance, buy over-priced coffees from hipster barristas.</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">What is novel in this new model is of course the ‘As long as X is true’ clause - some sort of continuous check of the user’s context that serves to better bind them to the original authentication. </span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Contrast this new model with traditional web-based authentication, in which, after the user presents some password (inevitably derived from their favourite sports teams name) the authentication server sets some session cookie </span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial; font-size: 15px; font-weight: bold; vertical-align: baseline;">‘As long as T seconds haven’t expired, no need to Y’</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">In this model, nothing binds the user to the authenticated browser session and so prevents somebody else from hijacking that session - (which if of course is why those who (perversely) login to their banks and other sensitive resources from public kiosks are reminded to sign out when done).</span><br />
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span>
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Even in this new model, there will be differences in the certainty with which the persistence of X can be determined - the Nymi and Apple Watch, because they more tightly bind the user to the authenticating device, would likely offer more assurance than the Samsung Gear (I can take the Gear off my wrist and the S5 will be oblivious).</span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Of course, the ‘As long as X’ condition is only viable if there are local sensors able to monitor the state of X - whether Bluetooth proximity, or skin contact, or heart rate measurement, or future buttock-to-sofa contact etc. </span></div>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">But fortunately the things that we are more and more surrounding ourselves with, even if primarily intended for some other purpose (think light bulbs, thermostats, and garage doors), will provide those sensors and so the ability to monitor all the different X’s we can think up.</span></div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com2tag:blogger.com,1999:blog-12447072.post-50715891271611756032014-02-07T07:15:00.000-05:002014-02-07T07:15:07.693-05:00Something you have (and some other things you have)The trinity of 'Something you know, something you have, and something you are' is the default model for describing authentication options.<br />
<br />
The three are traditionally described as follows<br />
<br />
<ol>
<li>The 'know' factor is a secret like a password or a PIN. </li>
<li>The 'have' factor is some physical object in your possession. </li>
<li>The 'are' factor is a biometric like finger or retina print.</li>
</ol>
<div>
Think about the 'have'. It's clearly not enough to merely have possession of a SecureId or smart phone. You have to demonstrate (or prove) possession of that object. Typically, possession is proved by entering in some OTP, or responding to a challenge sent to that object. </div>
<div>
<br /></div>
<div>
Now consider the 'know'. When I enter a password to login, what am I doing other than <b>proving possession</b> of (the knowledge of) the shared secret?</div>
<div>
<br /></div>
<div>
And for the 'are' factor, when I enter Canada using a Nexus kiosk, what am I doing other than <b>proving possession</b> of my retinas?</div>
<div>
<br /></div>
<div>
Would it not be simpler to model all authentication operations as </div>
<div>
<br /></div>
<div style="text-align: center;">
<b>Something you have (with various proof mechanisms) </b></div>
<div style="text-align: center;">
<b><br /></b></div>
<div style="text-align: left;">
We are headed to a future where the things we have (see <a href="http://www.getnymi.com/">this</a>) will be more and more involved in our authentication. While the phone may have primacy at the moment, over time it will become just one of many devices floating around us with an opinion on our status & presence (and an ability to assert it). </div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
So perhaps the ultimate model for describing authentication is </div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: center;">
<b>Some things you have (with various proof mechanisms) </b></div>
<div style="text-align: center;">
</div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com2tag:blogger.com,1999:blog-12447072.post-30046080091993970632014-02-07T06:46:00.000-05:002014-02-07T06:46:49.287-05:00You can take it with you (if you have a super long ethernet cable)In a post titled '<a href="http://gigaom.com/2014/01/08/can-you-take-it-with-you-uninstalling-the-internet-of-things/?imm_mid=0b70cd&cmp=em-na-na-na-newsltr_solid_20140206_direct">Can you take it with you? Uninstalling the internet of things</a>', Stacey Higginbotham considers how the installed base of home automation gear will impact moving households.<br />
<blockquote class="tr_bq">
<i>of the installed $250 thermostats or the $60 light bulbs, what comes with you if you have to move</i></blockquote>
Well clearly the fridge is coming with.<br />
<br />
Two commenters propose what seems to me the smartest (as it minimizes effort) route<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihqQap2fDCvUyAQoxKsXkg4X-UXzZpGidadzvRiit_tzHqEzpOWBx_dIcqv-bnsHjMd3-6eAE0WtZPBQzPaYwrEzoah3hZZaJKQeugCd3gt1y-GHKzKIc0feB04NXYKhXgQHh8jg/s1600/Screen+Shot+2014-02-07+at+6.11.45+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihqQap2fDCvUyAQoxKsXkg4X-UXzZpGidadzvRiit_tzHqEzpOWBx_dIcqv-bnsHjMd3-6eAE0WtZPBQzPaYwrEzoah3hZZaJKQeugCd3gt1y-GHKzKIc0feB04NXYKhXgQHh8jg/s1600/Screen+Shot+2014-02-07+at+6.11.45+AM.png" height="267" width="400" /></a></div>
<br />
Bob Sanders' comment hilites a procedure & mechanism that I don't think has received sufficient attention as yet.<br />
<br />
What would it look like for the new owner to 'establish his own credentials'? What accounts need be created? What assistance would the new owner be given - without the inevitably discarded original owners manual?<br />
<br />
How would the privacy of the previous owner be ensured? Should all data be erased and the new owner start from a (freshly) blank slate? But as there can be value in historical data (why are my heating costs significantly more than the previous owner's? etc) could we contemplate moving overly some suitably anonymized version of the data (presuming consent)?<br />
<br />
Beyond the devices themselves, what of the IFTTT-type rules that the previous owner might have defined for their operation? A lighting system is much more valuable with appropriate customized themes, such as 'Watching a movie'. Are these rules & patterns transferable to the new owner? <br />
<br />
It seems to me that transitioning a device from one user to another is a special case of the more general mechanism of how to bind a fresh from factory device to its first user - and the associated questions.<br />
<br />
<ul>
<li>How are these two identities associated?</li>
<li>How and where is the user's consent captured?</li>
<li>How is that consent manifested? How is it revoked?</li>
<li>How is the device added to the home network? </li>
</ul>
<div>
Bob posed his question in terms of 'credentials', but those are I think simply a manifestation of the more fundamental identities involved. </div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-74526784762695474142013-12-17T13:34:00.003-05:002013-12-17T13:35:07.873-05:00An IoT continuumCurrently, the burden falls on us humans to 1) sense the world around us 2) analyze that sensory data & decide how to best deal with it 3) act on that world accordingly<br />
<br />
The Internet of Things will change that - evolving from systems that help us with #1 to eventually helping us deal with #2 & #3.<br />
<br />
Consider a story, loosely based on reality, with progressively greater assistance provided to the handsome protagonist<br />
<br />
<ol>
<li>I look out the window and see snow coming down hard. I decide to leave early for a trip to the airport. Once in the car, I engage the 4-wheel drive.</li>
<li>I get an SMS from a weather alert service notifying me of snow squalls in the area. I decide to leave early for a trip to the airport. Once in the car, I engage the 4-wheel drive.</li>
<li>I get an email recommending I leave now for my trip to the airport - given snow squalls in the area. Once in the car, I engage the 4-wheel drive.</li>
<li>I get an email recommending I leave now for my trip to the airport - given snow squalls on my typical route. As I turn the ignition key, the car auto engages the 4-wheel drive.</li>
<li>My Home Concierge recommends I leave now for my trip to the airport - given snow squalls on my preferred route. Once I confirm the change, the car turns itself on, pre-warms the cabin, and auto engages the 4-wheel drive.</li>
</ol>
<div>
If the Internet of Things can get my two teenage sons to have the driveway shoveled - I won't even get my shoes wet.</div>
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com1tag:blogger.com,1999:blog-12447072.post-2885174255214142732013-11-18T09:48:00.000-05:002013-11-18T09:53:42.402-05:00Things that go bump in the nightMy daughter's best friend's family (let's call them the Smiths) recently moved to the other side of the country (unfortunately selfishly bringing their daughter). My daughter is saddened by this.<br />
<br />
To some extent, I see my role as trying to minimize large-scale sadness increases for my children (also my wife I guess though that definitely wasn't in our vows so that's mostly bonus the way I see it).<br />
<br />
Consequently, I'm looking for any mechanisms that might help my daughter with the change.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7TS57L-OLzXmKTbS6KRaoDq9595gus5zTQ6IAFH659uu9UWqoJHTYVLCa46OSUt3P3C4qhEjk5_VNlaix_8F-jSBY5Mfj4HR5gD0ZUVLip0vvKbKrhiHbRzxaR9tJRgLoVRxelg/s1600/gnl_set_network.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="110" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7TS57L-OLzXmKTbS6KRaoDq9595gus5zTQ6IAFH659uu9UWqoJHTYVLCa46OSUt3P3C4qhEjk5_VNlaix_8F-jSBY5Mfj4HR5gD0ZUVLip0vvKbKrhiHbRzxaR9tJRgLoVRxelg/s200/gnl_set_network.jpg" width="200" /></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7TS57L-OLzXmKTbS6KRaoDq9595gus5zTQ6IAFH659uu9UWqoJHTYVLCa46OSUt3P3C4qhEjk5_VNlaix_8F-jSBY5Mfj4HR5gD0ZUVLip0vvKbKrhiHbRzxaR9tJRgLoVRxelg/s1600/gnl_set_network.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><br /></a>Might technology help?<br />
<br />
The girls are already using <i>explicit</i> connectivity technology, some iOS app called Bump & numerous 2-hour FaceTime sessions in which mine and the Smith's households' respective dogs are forced to appear on camera in humiliating costumes.<br />
<br />
Explicit mechanisms are definitely important for keeping remote friends feeling connected, but so also can be <i>implicit</i> or passive mechanisms - such as the <a href="http://goodnightlamp.com/">Good Night Lamp</a>.<br />
<br />
<a href="http://www.forbes.com/sites/danielnyegriffiths/2013/02/05/kickstarting-over-good-night-lamps-kick-smart-response/">According</a> to Forbes<br />
<blockquote class="tr_bq">
<span style="line-height: 24px;"><span style="font-family: Times, Times New Roman, serif;">The Good Night Lamp is a simple set of lamps – one big, one or more little. When the big one is turned on, the little ones turn on. When the big one is turned off, its junior partners also turn off. More junior lamps can be added to the network, but that, at heart, is the whole offer. There is nothing to tinker with or customize – it is a simple point of presence, sent over the Internet.</span></span></blockquote>
This would be perfect for the girls. But unfortunately there are no Good Night Lamp kits available for purchase - they're sold out after their initial run.<br />
<br />
<div>
Coincidentally, I have a <a href="http://www.smartthings.com/">Smartthings </a>kit of various things - can I not use Smartthings to duplicate the GNL use case?</div>
<div>
<br /></div>
<div>
<b>Use Case</b></div>
<blockquote class="tr_bq">
When my daughter performs some explicit action, turn on/off bedside lamp of her friend in Vancouver. And vice versa. </blockquote>
<div>
<b>Tools</b></div>
<div>
<br /></div>
<div>
My Smartthings kit includes </div>
<div>
<ul>
<li>Hub</li>
<li>Multi</li>
<li>Presence</li>
<li>Outlet</li>
<li>Motion</li>
</ul>
<div>
<b>Implementation</b></div>
</div>
<div>
<b><br /></b></div>
<div>
Temporarily putting aside the two household aspect, I could use a Hub, Multi and Outlet to satisfy the use case within my own house - using IFTTT to tie it all together.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoYo2jRkAX4j0IvDwYxXVmte7nvgnYgqV5elwyXiv3qN_lWOvqSWLKugua8egPaUkQQ9Dek5XQqROXy_8KlJr9_fXp4N8DhssM21sp1gNvaZEYoWlePyAsb_tDkGCIkBb3j8ydvA/s1600/Screen+Shot+2013-11-18+at+9.13.08+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="283" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoYo2jRkAX4j0IvDwYxXVmte7nvgnYgqV5elwyXiv3qN_lWOvqSWLKugua8egPaUkQQ9Dek5XQqROXy_8KlJr9_fXp4N8DhssM21sp1gNvaZEYoWlePyAsb_tDkGCIkBb3j8ydvA/s400/Screen+Shot+2013-11-18+at+9.13.08+AM.png" width="400" /></a></div>
<div>
<br /></div>
<div>
When the Multi switch is closed (the two halves placed together), the Outlet is turned on, and so any light plugged into turned on as well. And vice versa.</div>
<div>
<br /></div>
<div>
To deal with two different households, I could purchase another Smartthings Hub, Multi, and Outlet - ship them to the Smiths and then duplicate the above rules, although <i>inter</i>-household and not <i>intra</i>.</div>
<div>
<br /></div>
<div>
This would work, but at the cost of me bearing the full financial burden (and the Smith girl is missing a friend too right?) of effectively purchasing two Smartthings kits and distributing the various pieces over the country. </div>
<div>
<br /></div>
<div>
Preferable (to me if not the newly trendy, sodden and real estate-indebted Smiths) would be a model where it is the Smiths that purchase the second Smartthings kit - and yet we are still able to apply the above logic, albeit based on explicit authorization rules (the Smiths can control my outlet, and I can control their outlet) rather than implicit logic (all the things belong to me).</div>
<div>
<br /></div>
<div>
For Smartthings to support this would require</div>
<div>
<ol>
<li>an invitation mechanism whereby I can request the Smiths to assign me permissions over their household things</li>
<li>an authorization UX whereby I can assign the Smiths permissions to control my household things</li>
<li>an authorization framework by which the permissions of a given 'turn on Outlet' request from a household to the Smartthings cloud platform can be checked.</li>
</ol>
<div>
OAuth,OpenID Connect & UMA (User Managed Access) are identity & authorization standards that were designed to meet these sorts of requirements. </div>
</div>
<div>
<br /></div>
<div>
Of course, this sort of 'identity interoperability' across two smart households begs the question - shouldn't this work across different Home Automation platforms? What if the Smiths were to purchase <a href="http://www.wigwag.com/">WigWag</a> and not Smarthings? This sort of cross-platform interoperability neeedn't even imply a WigWag hub controlling a Smartthings Outlet - the interoperability could happen between the two respective clouds using HTTP & APIs.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-39989289073754721072013-11-15T07:25:00.000-05:002013-11-15T07:25:17.561-05:00Client authentication in MQTTAs <a href="http://pzf.fremantle.org/2013/11/using-oauth-20-with-mqtt.html">leveraged</a> by Paul Freemantle, the latest working draft of MQTT allows for (if not defines how to) use of OAuth access tokens in authenticating the client to the server/broker.<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">The CONNECT Packet contains Username and Password fields. Implementations can choose how to make use of the content of these fields. They may provide their own authentication mechanism, use an
external authentication system such as LDAP or Oauth [sic] tokens, or leverage operating system authentication mechanisms.</span></blockquote>
The spec also allows for client authentication through VPN or SSL. And also it seems inserting arbitrary credentials in the application payload as well.<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">An implementation might allow for authentication where the credentials are flowed in an Application
Message from the Client to the Server.</span></blockquote>
Separate from the interoperability challenge presented by so many different client authentication mechanisms, there is (to my mind) a more fundamental issue with MQTT's client authentication model.<br />
<br />
There are both <span style="font-family: Courier New, Courier, monospace;">ClientID</span> and <span style="font-family: Courier New, Courier, monospace;">Username</span> params allowed on the <span style="font-family: Courier New, Courier, monospace;">CONNECT</span> message. This would allow for separate identification of both the MQTT client and any user that that client was sending messages on behalf of. This seems appropriate - allowing for a single client to potentially represent different users over time. But there is only a single <span style="font-family: Courier New, Courier, monospace;">Password</span> (or equivalent) parameter on the <span style="font-family: Courier New, Courier, monospace;">CONNECT</span> and it appears to serve double duty for both authentication of the client and also any user.<br />
<br />
Because there is only one <span style="font-family: Courier New, Courier, monospace;">Password</span> parameter, it seems you can't authenticate both the client <i>and</i> a user simultaneously on the same <span style="font-family: Courier New, Courier, monospace;">CONNECT</span>.<br /><br />
If you did need to authenticate both client & user simultaneously, it would seem you would need to do something like<br />
<br />
<ol>
<li>use client-authn SSL to authenticate the client & use the <span style="font-family: Courier New, Courier, monospace;">Password</span> field for the user, or</li>
<li>use the <span style="font-family: Courier New, Courier, monospace;">Password</span> field for client & some application message param for the user (or vice versa?)</li>
</ol>
<br />
Choice is good except when it isn't.....<br />
<br />
If MQTT allowed for a '<span style="font-family: Courier New, Courier, monospace;">client_pwd</span>' (name it what you will) to be paired with the existing <span style="font-family: Courier New, Courier, monospace;">Clientid</span> parameter, and thereby distinguish between credentials for the client (<span style="font-family: Courier New, Courier, monospace;">client_pwd</span>) and the user (<span style="font-family: Courier New, Courier, monospace;">Password</span>), then the whole situation would be cleaner.<br />
<br />
Even cleaner would be to define a new <span style="font-family: Courier New, Courier, monospace;">CONNECT</span> field called '<span style="font-family: Courier New, Courier, monospace;">access_token</span>', and use that instead of forcing OAuth tokens into the existing parameters (which can be problematic as Paul discovered).<br />
<blockquote class="tr_bq">
I couldn't encode the token as the password, because of the way
Mosquitto and mosquitto_pyauth call my code. I ended up passing the
token as the username instead. I need to look at the mosquitto auth
plugin interface more deeply to see if this is something I can fix or I
need help from Mosquitto for.</blockquote>
<br />
<br />
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-42583193743896697972013-11-14T10:11:00.002-05:002013-11-14T10:11:09.697-05:00OAuth binding for MQTTPaul Freemantle <a href="http://pzf.fremantle.org/2013/11/using-oauth-20-with-mqtt.html">blogs</a> about some experimenting he has done around using OAuth within MQTT - specifically using an OAuth access token in the place of a username password.<br />
<blockquote class="tr_bq">
I've been thinking about security and privacy for IoT. I would argue
that as the IoT grows we are going to need to think about federated and
user-directed authorization. In other words, if my device is publishing
data, I ought to be able to decide who can use that data. And my
identity ought to be something based on my own identity provider.</blockquote>
Choir member here appreciating the sermon.<br />
<br />
Paul appeared to focus on how the MQTT client, once having obtained an OAuth access token reflecting the relevant user's consent to some set of operations (captured in a scope), used that token on its CONNECT messages to a MQTT broker. In the end, he used the existing MQTT username parameter to carry the token.<br />
<br />
Coincidentally, I was thinking about the same integration yesterday, though focussed less on how to bind the tokens to the MQTT messages and more on how we might leverage MQTT's existing pub/sub model to get the token to the Client.<br />
<br />
Something like<br />
<ol>
<li>Client send the username/password on MQTT CONNECT message</li>
<li>Client sends SUBSCRIBE message for a topic of 'access_token/#'</li>
<li>MQTT broker responds with a PUBLISH message carrying the access
token.</li>
<li>Client discards password, stores access token</li>
</ol>
On subsequent interactions (as long as the token hadnt expired)
with the broker, the client would use the token instead of the
username/password combination.<br />
<br />
The above pattern, namely the client directly exchanging a username/password for an access token, mirrors the OAuth Resource Owner Credentials grant type - allowed for in OAuth but not recommended.<br />
<br />
There are definite advantages to instead leveraging a web browser (as Paul indicated he had used) for the token issuance, including<br />
<br />
<ol>
<li>password need not be presented to broker</li>
<li>allows for federated user authentication (ie at some other IdP)</li>
<li>allows for a detailed & granular consent UI</li>
</ol>
<div>
But perhaps the above issuance model would be easier to layer onto simple MQTT clients - leveraging as it does the existing flow.</div>
<div>
<br /></div>
<br />
<br />
<br />
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-14103082037458984052013-10-30T08:54:00.000-04:002013-10-30T08:54:13.675-04:00Smartthings - binding thing to userSome 'things' need to be bound to a user identity in order to allow for differentiated authorizations or reporting.<br />
<br />
Follows is how this binding works for Smartthings<br />
<br />
I placed my order at Smartthings.com. When the package arrived, it included a registration code. I assume all the thing serial numbers (or equivalent identifiers) is indexed by that code as part of the packaging & shipping process.<br />
<br />
Though I'm not sure, I don't believe the registration code was bound to my account at issuance time (even though it could have been because I was logged in at the time). Binding will happen post shipping.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeNbrWkNK4ixte7HMn_YMJCM7T6pONEJA82oXteAxXVTdmHfz6MOdPITSBwcwxCaOon-lY2X1GZozFtJ3_E6az8j2aTGM8lWR4QIll7mssiTbTuFgytgSciVBlXMDgtT1u4ZGRvA/s1600/Screen+Shot+2013-10-25+at+11.51.40+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeNbrWkNK4ixte7HMn_YMJCM7T6pONEJA82oXteAxXVTdmHfz6MOdPITSBwcwxCaOon-lY2X1GZozFtJ3_E6az8j2aTGM8lWR4QIll7mssiTbTuFgytgSciVBlXMDgtT1u4ZGRvA/s400/Screen+Shot+2013-10-25+at+11.51.40+AM.png" width="400" /></a></div>
<br />
<br />
I then download and install the Smartthings app (here Android). Below is the initial login screen<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBrTFGFYY7_VWt59kfSVZc37OnHLiBP2Rh5D2cCcylzzTxRnoaWluUMACrasPdfPmTnXkqMkJ0hk7F_MOmlxCBeNhTq2ur5IwPQcC0KRmHSl5_z8YEFWMAXK1SOQ8a1Iw0CjyW7Q/s1600/export_15.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBrTFGFYY7_VWt59kfSVZc37OnHLiBP2Rh5D2cCcylzzTxRnoaWluUMACrasPdfPmTnXkqMkJ0hk7F_MOmlxCBeNhTq2ur5IwPQcC0KRmHSl5_z8YEFWMAXK1SOQ8a1Iw0CjyW7Q/s320/export_15.png" width="200" /></a></div>
<br />
After logging in, I am prompted to plug in the Smartthings hub, connect it by ethernet to the home router, and then enter the registration code into the app<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8FXWgE3kKZKTw-SWeU6aAcOzX1Y8UgSK5pGhNRkkBz1wGiIMEyQEoCQIMeRHHZcl_fyo5imq6wUaZBdiCeL0BEk02SyhxISfrbtNLqPRlG23sTX1y_1tPXkPdVRkDq-Iec5_5Vg/s1600/export_17.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8FXWgE3kKZKTw-SWeU6aAcOzX1Y8UgSK5pGhNRkkBz1wGiIMEyQEoCQIMeRHHZcl_fyo5imq6wUaZBdiCeL0BEk02SyhxISfrbtNLqPRlG23sTX1y_1tPXkPdVRkDq-Iec5_5Vg/s320/export_17.png" width="200" /></a></div>
<br />
User account is bound to code, and code is bound to device identifiers - so consequently user account can be bound to device identifiers.<br />
<br />
It is through the temporary identifier of the code that Smarthings is able to know that a given motion sensor is under my account and so apply a permissions model based on this binding, ie I can manage them but nobody else (unless I stipulate so). Even more basic, when the Smartthings cloud receives sensor data from a particular thing/hub combination, it is able to associate that data with my account.<br />
<br />
I recently purchased a Fitbit Aria scale. The Aria used a completely different mechanism to associate the scale with my existing Fitbit account. Area seems ripe for usability testing.<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-34230515411543565812013-10-18T07:50:00.002-04:002013-10-18T08:00:26.245-04:00Assurance over timeConsider a traditional authentication event.<br />
<br />
The user logs in at a given time t<sub>0</sub> and establishes some initial level of assurance. As time goes by, that assurance drops, the rate dependent on the context, ie public kiosk, etc.<br />
<br />
A graph of assurance over time looks something like<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZBX-JlaVxqE-Qpw7O5LcZ_gWuuf3gH1n24i8yGUEdQzsEUI0Ajl7uUs8kRh22vsmsr3Aa3rHTMo3StsFCfHy-xmxh_wp-uypxP3qGi8h8sEvL1S89pSF1lXRvhtk_4ZXF1T5QDw/s1600/Screen+Shot+2013-10-18+at+7.28.52+AM.png" imageanchor="1"><img border="0" height="286" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZBX-JlaVxqE-Qpw7O5LcZ_gWuuf3gH1n24i8yGUEdQzsEUI0Ajl7uUs8kRh22vsmsr3Aa3rHTMo3StsFCfHy-xmxh_wp-uypxP3qGi8h8sEvL1S89pSF1lXRvhtk_4ZXF1T5QDw/s400/Screen+Shot+2013-10-18+at+7.28.52+AM.png" width="400" /></a><br />
<br />
To prevent this decline, you can require that the user re-authenticate whenever the assurance hits some threshold a<span style="font-size: x-small;"><sub>t</sub></span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjqd-RnpalTpQp00zWFC6Z8gYEdkv74JfeEMpMj9zDXDPJmZ8TYrhsqliN7-Rd7LF2EcAiHT71iaw7J0fqBKJRssCLbnOKU7S06FZpxBzteDruxvcYCMWns2-EW4-RVBpwA6Zt_g/s1600/Screen+Shot+2013-10-18+at+7.30.10+AM.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="312" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjqd-RnpalTpQp00zWFC6Z8gYEdkv74JfeEMpMj9zDXDPJmZ8TYrhsqliN7-Rd7LF2EcAiHT71iaw7J0fqBKJRssCLbnOKU7S06FZpxBzteDruxvcYCMWns2-EW4-RVBpwA6Zt_g/s400/Screen+Shot+2013-10-18+at+7.30.10+AM.png" width="400" /></a></div>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
An alternative to using explicit additional logins (as above) is to maintain assurance above a<span style="font-size: x-small;"><sub>t</sub></span> by monitoring implicit factors such as location, continuous typing, facial recognition, etc<br />
<br />
<b>Nb:</b> the 'how' of detecting & monitoring these passive or implicit factors clearly demands some new pieces on the network. Depending on where this functionality sits, we may also need new mechanisms & protocols for communicating the information around. <br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4YaPvExDLf2riArNNZWP8nP2pnwaaYQo4lzgDHFtjvQ_SIa-L9TnrFNg75KuHkZknxEQGELq4FUHPdTwfZDJFzVTqX5mtHsfZGPbssGCrjUWC7fi8aHTvbBfJznPOjKWM7tR2tw/s1600/Screen+Shot+2013-10-18+at+7.33.55+AM.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="263" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4YaPvExDLf2riArNNZWP8nP2pnwaaYQo4lzgDHFtjvQ_SIa-L9TnrFNg75KuHkZknxEQGELq4FUHPdTwfZDJFzVTqX5mtHsfZGPbssGCrjUWC7fi8aHTvbBfJznPOjKWM7tR2tw/s400/Screen+Shot+2013-10-18+at+7.33.55+AM.png" width="400" /></a></div>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
From the user's PoV, this passive model has advantages - minimizing as it does the pain of explicit logins.<br />
<br />
Ultimately, using a combination of explicit & implicit authentication factors appears to be emerging as the optimal balance of security & usability.Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-582671164830016932013-10-18T06:23:00.001-04:002013-10-18T06:23:54.147-04:00I don't even drink milk!Along with the smart toaster, a fridge that can sense when the household is about to run out of milk and send a compensating order to the local supermarket is presented as home automation's killer app.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik_FXToibDsz0q4L21wxAuvULEPlPLsdpUwua3dnDTZRt3sFbidC7K_2MUd29kalUi5KA8PLIrgvugXGWJaxQf4EZK_f-rnRAfQBL47gWudXeylkIeAkKCZIhDi4UH6xJoDdurcQ/s1600/fridge2913.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik_FXToibDsz0q4L21wxAuvULEPlPLsdpUwua3dnDTZRt3sFbidC7K_2MUd29kalUi5KA8PLIrgvugXGWJaxQf4EZK_f-rnRAfQBL47gWudXeylkIeAkKCZIhDi4UH6xJoDdurcQ/s200/fridge2913.jpg" width="198" /></a></div>
<br />
Couple of things<br />
<ol>
<li>Ahem, Webvan?</li>
<li>Lactose intolerance is a serious health issue for many</li>
</ol>
<div>
Now a fridge that could monitor 'beer' metrics - that's a use case!</div>
<div>
<br /></div>
<div>
And it's more interesting from an identity perspective. </div>
<div>
<br /></div>
<div>
Any fridge can order milk. Only fridges that exceeds the local age of majority can order beer or wine.</div>
<div>
<br /></div>
<div>
Or more precisely, only fridges acting on behalf of a human who exceeds the local age of majority can order beer or wine.</div>
<div>
<br /></div>
<div>
That demands an identity model in which</div>
<div>
<ol>
<li>The fridge can obtain an identity token for individual users - these to be attached to the 'Buy beer' API calls to the local <a href="http://en.wikipedia.org/wiki/D%C3%A9panneur">depanneur</a></li>
<li>The token contains (or references) the user's 'age' attributes </li>
<li>The token is issued from an identity provider that is accredited to issue age attributes</li>
<li>The depanneur can validate the token as coming from a trusted authority, look at the age attribute, and so determine that the fridge's request can be authorized.</li>
</ol>
<div>
OpenID Connect is tailor made for the above set of requirements. </div>
</div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-60847907861803343642013-10-16T06:52:00.002-04:002013-10-16T06:52:49.292-04:00Users, groups & thingsBelow is an attempt to tease out a taxonomy of Internet of Things use cases - differentiating based on<br />
<br />
<ol>
<li>on whose behalf the thing acts on (whether a data subject or not) </li>
<li>the data subject of the data the thing collects & shares</li>
</ol>
<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidf3w8rhv2q-DRnwWp3vkM-vx6WrIbykC7AOD_gqxJlrdMa9lJa4gxzj1KgePegDq2aLfb7u2TB2UanhCOVdD1lISFtsJKc1HSrwAZJHPDJYV4cjhKdFweI-IkjPn5kG3fVW9WCQ/s1600/Screen+Shot+2013-10-16+at+6.13.30+AM.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="268" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidf3w8rhv2q-DRnwWp3vkM-vx6WrIbykC7AOD_gqxJlrdMa9lJa4gxzj1KgePegDq2aLfb7u2TB2UanhCOVdD1lISFtsJKc1HSrwAZJHPDJYV4cjhKdFweI-IkjPn5kG3fVW9WCQ/s400/Screen+Shot+2013-10-16+at+6.13.30+AM.png" width="400" /></a></div>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
A Fitbit Flex, Jawbone Up, Nike Fuel Band etc all collect the data of a given single user. It is that same user that the thing acts on behalf of. This makes for a pretty straightforward identity model - single device, single user.<br />
<br />
At any given time, a smart scale like a Withings or Fitbit Aria is also representing a single user (and sharing that user's data). But, unlike the wearables above, for this sort of thing that user can change over time. Consequently, such a thing has to support multiple different users - including UI that allows users to select themselves from a list. Ideally, such a thing (and associated apps) would also support differentiated consent/authorization for all the different users. For instance, should my wife be allowed to see my weight data (and surreptitiously try to curtail my beer consumption as a result?) That's not a world I want to live in you, do you?<br />
<br />
The archetypical 'smart toaster' would need this sort of identity model if it were to allow each breakfast eater to have personalized toast patterns.<br />
<br />
A thermostat like a Nest, or a fridge, etc collects the data associated with a group of users (the family members) and can be said to act on behalf of the user that bought, installed, configured & registered it (not the teenager in all likelihood). Because the data is aggregated, the privacy risks are different than for a device that acts only for single users.<br />
<br />
Things can also act autonomously, ie be 'doing their thang' not on behalf of a user of that thing, but for themselves (or more precisely some unnamed admin or even a corporate entity).<br />
<br />
A residential electricity meter, like the Nest, collects data associated with a group of users (the family) but, unlike the Nest, is not under the governance of the homeowner. Instead the meter is owned and operated by the electricity provider. While the provider may give access to the homeowner, its fundamental purpose is to determine how much to charge per month.<br />
<br />
Likewise, nobody would argue that a speed camera snapping a pic of me (only slightly exceeding the limit, which everybody agrees is ridiculously low on that stretch of road) is acting on my behalf. It's operating on behalf of the local region or county tax revenues. Along the other axis, those cameras can focus on (and differentiate) individual drivers or post-game hockey final loss mob members - and so create privacy concerns.<br />
<br />
And probably the biggest use case (in number of sensors & perhaps $$) - all those factory floor robots, air quality sensors, street lights & water pipes silently reporting operational status.<br />
<br />
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com4tag:blogger.com,1999:blog-12447072.post-21268472159640186372013-10-14T06:38:00.001-04:002013-10-14T06:38:43.634-04:00Internet of Smells<div class="separator" style="clear: both; text-align: left;">
If I've learned anything in 20 years of marriage, it is this</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<b>Hockey equipment must be aired out after use</b></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3QUwLl32-qCJylQD9LeMQj14pxy4sdQOQZEelbxcfFe-zFvVjUB5b3aPAnbOVMhNcgCejZMg3sT_E0f3kYrnw4C9YKE1eEBd4gzFrw3dYxxTVjk-PTe89xkv0aqh4NzQPA-UAhg/s1600/20131011_094347.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3QUwLl32-qCJylQD9LeMQj14pxy4sdQOQZEelbxcfFe-zFvVjUB5b3aPAnbOVMhNcgCejZMg3sT_E0f3kYrnw4C9YKE1eEBd4gzFrw3dYxxTVjk-PTe89xkv0aqh4NzQPA-UAhg/s400/20131011_094347.jpg" width="300" /></a></div>
<br />
Unfortunately every time the equipment is removed from the bag (enabling airing and thereby not negatively impacting marital complacency) there is a risk that it won't all be placed back in - with almost certain consequences for pain & bruising during the next game.<br />
<br />
What if every piece of equipment were able to report on its presence in (or more critically absence from) the bag as I pull it out of the garage?<br />
<br />
How would the system learn that a particular piece of protective equipment was meant to be in the bag and, if not, alert me to that fact?<br />
<br />
One model would be for me to manually specify a rule, ie 'At 6.15am on Tuesday & Thursday mornings, alert me if any of the 'Goalie Equipment' group of sensors are not within 1 m of the 'Goalie Hockey bag' sensor'.<br />
<br />
Sounds like a lot of work (for myself).<br />
<br />
Alternatively, the system could over time, recognize the above implied pattern, and build a rule itself alerting me whenever that pattern was violated.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-32693952606780875582013-10-11T09:30:00.001-04:002013-10-14T07:08:57.947-04:00Consent anti-patterns for Internet of ThingsUser-control will be key for many (but not all of course) Internet of Thing use cases. A key piece of such control will be collecting the User's consent for<br />
<br />
<ol>
<li>a given thing to act on their behalf</li>
<li>a given application to access/control the thing</li>
</ol>
<br />
Follows are examples of (to my mind) 'bad' consent UI.<br />
<br />
<b>NB</b> Although these examples are not IoT-specific, I believe the principles of what makes a good consent UI are still applicable.<br />
<br />
<b>Anti-Pattern 1 - Optional vs Required permissions</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHcvOCBESuPiTovvq8lpEfdD0tmp9GSSV8hbESEOCrMYpyjaS4QcyRebfbcdIOV38RzNmR1dbVH45MqkVyBalp28x98z5hQQTFVL7_pso-cJbfY7ODe-qrj6ToNoysqrM08aVSUQ/s1600/Screen+Shot+2013-10-11+at+9.10.48+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="220" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHcvOCBESuPiTovvq8lpEfdD0tmp9GSSV8hbESEOCrMYpyjaS4QcyRebfbcdIOV38RzNmR1dbVH45MqkVyBalp28x98z5hQQTFVL7_pso-cJbfY7ODe-qrj6ToNoysqrM08aVSUQ/s320/Screen+Shot+2013-10-11+at+9.10.48+AM.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
In the IoT context, what permissions are mandatory for the thing to have, and what are merely 'nice to have'? For example, if the thing is <i>merely</i> a sensor, dont ask for 'write' permissions.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>Anti-pattern 2 - Unclear consent persistence</b></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgisndjovo0WDZbGzi_rZ3a3ciAP6ubKVxT12s0tbkDaEA1MgYEPgXAFQ4v_wWxUoV7_3gADRFbzEWwBuSLos3rwwvnbPV7tIsCw6GqBekuAISguV0ip0PEjgwRYeDkM-QZbTQ1RQ/s1600/Screen+Shot+2013-10-11+at+9.11.15+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="244" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgisndjovo0WDZbGzi_rZ3a3ciAP6ubKVxT12s0tbkDaEA1MgYEPgXAFQ4v_wWxUoV7_3gADRFbzEWwBuSLos3rwwvnbPV7tIsCw6GqBekuAISguV0ip0PEjgwRYeDkM-QZbTQ1RQ/s320/Screen+Shot+2013-10-11+at+9.11.15+AM.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Will I be interacting with the thing going forward? or is this a one-night stand, e.g. allowing a bus stop to add the bus schedule to my calendar? Consent should reflect this</div>
<div class="separator" style="clear: both; text-align: left;">
<b><br /></b></div>
<div class="separator" style="clear: both; text-align: left;">
<b>Anti-pattern 3 - Confuse The User as to Where They Are</b></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ52PV_1xD7QUzdquzjkf4xkaed8Q_io8uaHd14VQiZvIWie5q5W7DGF2xwAXUyi5iRk2eq03QBouTPw8oAclFO0kF1csQDJbKqTUjYw88pd_dGgAelwyC_tb8xGordPrGnzdqlA/s1600/Screen+Shot+2013-10-11+at+9.11.37+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="294" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ52PV_1xD7QUzdquzjkf4xkaed8Q_io8uaHd14VQiZvIWie5q5W7DGF2xwAXUyi5iRk2eq03QBouTPw8oAclFO0kF1csQDJbKqTUjYw88pd_dGgAelwyC_tb8xGordPrGnzdqlA/s320/Screen+Shot+2013-10-11+at+9.11.37+AM.png" width="320" /></a></div>
<br />
Make sure the user knows to whom they are giving permissions.<br />
<br />
Here is another example of confusing UI/UX. The Saga lifestreaming app has sent me to Fibit's site so that I can authorize Saga's access to my step data. But, because this is happening in a browser window embedded within the Saga app (as opposed to the default phone browser), its not clear that I'm actually presenting my Fitbit password <i>to</i> Fitbit.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOZPuWEusIcl90qJTk9jWJfL31JX7qeG1LMXXPCA-1FESmIyWF86DdKJ4OpTEevfB0MpvXXTfUwO2Fmt0N9ch7WPuhR09eSRKcfaTo7bSzFq0MWk-tie-uvfmtv8zBEhvslWJKpA/s1600/Screenshot_2013-10-13-17-16-40.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOZPuWEusIcl90qJTk9jWJfL31JX7qeG1LMXXPCA-1FESmIyWF86DdKJ4OpTEevfB0MpvXXTfUwO2Fmt0N9ch7WPuhR09eSRKcfaTo7bSzFq0MWk-tie-uvfmtv8zBEhvslWJKpA/s400/Screenshot_2013-10-13-17-16-40.png" width="250" /></a></div>
<br />
<br />
Of course, just as important as providing the user intuitive mechanisms for granting permissions to things & applications is providing them a mechanism to view & manage (eg revoke) those permissions over time.<br />
<br />
<h3>
Anti-pattern 4 - Non-exhaustive list</h3>
<div>
Will the Saga app actually be able to see everything else other than my password?</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2Pg5pL15-nVAoxKvka04XO3XMItdpMLMUEVD-PVOxrkw8_tXYu4fy8KH5sIzWW7hLvsTqmLZ1vxOkwTnemqTZxQ6VqSbx0a9OrkQasBm1QbFcGqmDf51OAf4qyq0LahLOPCf0IQ/s1600/export_30.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2Pg5pL15-nVAoxKvka04XO3XMItdpMLMUEVD-PVOxrkw8_tXYu4fy8KH5sIzWW7hLvsTqmLZ1vxOkwTnemqTZxQ6VqSbx0a9OrkQasBm1QbFcGqmDf51OAf4qyq0LahLOPCf0IQ/s400/export_30.png" width="250" /></a></div>
<div>
<br /></div>
<br />
<br />Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com1tag:blogger.com,1999:blog-12447072.post-19422189302708682722013-10-09T07:46:00.000-04:002013-10-09T07:47:10.502-04:00Complexity asymmetry & constrained devicesSecurity protocols differ in how they distribute complexity between 'asserting party' and 'relying party' - and so will differ in how applicable they are to use cases where the two actors have unequal capabilities.<br />
<br />
SAML assumes a relatively equal burden for the IdP & SP, e.g. both are assembling XML messages and may be signing those messages.<br />
<br />
OAuth 1.0a, with its multiple tokens and client crypto requirements, likewise placed on the client a relatively high burden.<br />
<br />
TLS can work in a symmetrical mode, one where both client & server are authenticated (and share the associated burden relatively evenly) and another where the client gets off easily (but doesnt get authenticated).<br />
<br />
OAuth 2.0, and so OpenID Connect, was designed to move most of the complexity <i>off</i> the client. Being an OAuth 2.0 or OIDC client is pretty simple - assemble some HTTP messages, send them to AS via browser, keep track of some tokens, and add those tokens as headers on API calls.<br />
<br />
So, for a constrained thing, OAuth 2.0 and OIDC make more sense than SAML (like I need to say that).<br />
<br />
When you pair OAuth 2.0 with server-only authentication TLS (or DTLS?), you get<br />
<br />
<ol>
<li>client authentication (via OAuth 2.0)</li>
<li>server authentication (via TLS) </li>
<li>data confidentiality (via TLS)</li>
<li>data integrity (via TLS)</li>
</ol>
<div>
and, critically, keep most of the complexity off the thing and instead on the server or gateway that is likely more capable of bearing the burden.</div>
<div>
<br /></div>
<div>
Client-authn TLS provides all of the above security characteristics, but with a different distribution of complexity.</div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-53868695020935708282013-10-08T10:08:00.001-04:002013-10-08T10:10:03.388-04:00Identities - Thing & UserThings will ship from the factory with an identity - either burnt into the firmware or embedded into the software.<br />
<br />
In home automation, wearable, & healthcare use cases, that thing identity will need to be associated with or bound to a user identity (or multiple user identities). Once this association is made, then any subsequent message from the thing can be understood to be occurring 'on behalf of' that particular user.<br />
<br />
In theory this binding could happen before purchase by the manufacturer/retailer provisioning some sort of identity credential before shipping to a customer (with an existing account) but more likely is that it happens after the thing is brought home.<br />
<br />
The binding mechanism can take different forms - it will depend on whether<br />
<br />
<ol>
<li>the thing has a UI</li>
<li>the thing interacts directly with its Cloud, as opposed to via some computer/phone etc</li>
</ol>
<br />
The different mechanisms will place different usability burdens on the User.<br />
<br />
For the Fitbit Flex, the binding happens via the desktop app<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRiG_DfJyWP8PM0aq1UfbbE7MSLdEdAUrgLHQ6TqDsKpCI2xiW9C_H94xFSdjZgz3CZ8jicGgom0TUrYHb8M8jUdkZ5MEKjHGbmMn_fTSH_ayf3xhfpXUYxpuYyXrpTPlw9IZ32A/s1600/Screen+Shot+2013-09-16+at+10.18.20+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="232" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRiG_DfJyWP8PM0aq1UfbbE7MSLdEdAUrgLHQ6TqDsKpCI2xiW9C_H94xFSdjZgz3CZ8jicGgom0TUrYHb8M8jUdkZ5MEKjHGbmMn_fTSH_ayf3xhfpXUYxpuYyXrpTPlw9IZ32A/s320/Screen+Shot+2013-09-16+at+10.18.20+AM.png" width="320" /></a></div>
<br />
Once logged into my Fitbit user account from my laptop, the Flex messages with the USB dongle and presumably passes its device identifier - this to be passed by the desktop app to the Fitbit cloud for the association to be recorded.<br />
<br />
When I receive my Smartthings kit (any day now), it appears it will be a more manual mechanism to bind particular devices to my user account<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqxVwlKhvN_KKSMelxr2U0tgoNi-YIStcpuxXXUrT4CEtBF37ojhrjJ4VrasbphC5naEuf86cP4mCpQGcAiO_gcEWvy0JdQHaXoI3GjgG2ikeZcO5Bx_YzmbgzPRjXWk7WWFNfxg/s1600/Screen+Shot+2013-10-08+at+9.38.44+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqxVwlKhvN_KKSMelxr2U0tgoNi-YIStcpuxXXUrT4CEtBF37ojhrjJ4VrasbphC5naEuf86cP4mCpQGcAiO_gcEWvy0JdQHaXoI3GjgG2ikeZcO5Bx_YzmbgzPRjXWk7WWFNfxg/s320/Screen+Shot+2013-10-08+at+9.38.44+AM.png" width="152" /></a></div>
<br />
<br />
Regardless of how it happens, after binding the cloud associated with the thing is able to say that 'Thing with identity X is acting on behalf of User(s) with identity Y(Z)'.<br />
<br />
How that association is manifested can also differ.<br />
<br />
Very non-optimal (though I'm sure it exists) would be for the user's password to be handed to the thing (or to a proxying gateway) and used on its API calls.<br />
<br />
Better would be an OAuth-type model, something like the following<br />
<br />
<ol>
<li>Thing asks its cloud server for an access token , presenting its own identifier/secret</li>
<li>Cloud server logs user in and says 'You OK with this?'</li>
<li>Cloud server issues token to Thing (and remembers the pairing of Thing & User)</li>
<li>Thing uses token on its API calls to Cloud</li>
</ol>
<div>
The advantages of this model are</div>
<div>
<ol>
<li>The user can be selective and granular in how they permission their things</li>
<li>The user can revoke the token when relevant (lost, stolen or sold thing)</li>
</ol>
<div>
<br /></div>
</div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-69147377974687782862013-10-07T11:51:00.002-04:002013-10-07T11:51:22.036-04:00OAuth for multi-thing coordination use casesLet's say you have a Fitbit wrist band for counting your steps and a Nest thermostat for controlling your home's temperature (if you have both you almost certainly also have 3-4 iDevices but let's ignore that for now).<br />
<br />
Both are great. Both give you visibility & control into areas of your life you were previously unaware of (blissfully or otherwise).<br />
<br />
But both are oblivious of the other - both operate in their own silos, defined by proprietary APIs, and likely different choices for radio protocol.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghopm6Rha81bbIkTo6VYx1I9YCvjq9BHVCMlCHfszPe0elZTibFXaDTNH5huykBZzMc5lGhGxdQT1mKKex8KXSxIqyuP1FW_8cChx27eoBH1i_izPiLDekgVPZXabwkccuyYZrtA/s1600/Screen+Shot+2013-10-07+at+11.03.43+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghopm6Rha81bbIkTo6VYx1I9YCvjq9BHVCMlCHfszPe0elZTibFXaDTNH5huykBZzMc5lGhGxdQT1mKKex8KXSxIqyuP1FW_8cChx27eoBH1i_izPiLDekgVPZXabwkccuyYZrtA/s320/Screen+Shot+2013-10-07+at+11.03.43+AM.png" width="317" /></a></div>
<br />
Because of this balkanization, interesting use cases that require coordination of the Fitbit and Nest are challenging or not even possible. For instance, if after a brisk walk on a hot day I would hope to return home to a nicely chilled house - my steps as counted by the Fitbit would need to be taken as input to a rules engine that could send an appropriate temperature adjustment message to the Nest.<br />
<br />
In the absence of the Fitbit and Nest stacks directly communicating, the only solution is to try to layer on the necessary coordination layer, as shown below<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUhZBrDlGXcdisjKzKKNijuy48nWjDw8bZkGwE1jdIHur9ShmqbEsUMwia2lbefBgHFVl4N_9PbAPXW_9Zl-TP6v8PHPM9B_B61da-vVDZN6g4pm2cxnc59K5dmFtHJBPLajvXJA/s1600/Screen+Shot+2013-10-07+at+11.14.19+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="249" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUhZBrDlGXcdisjKzKKNijuy48nWjDw8bZkGwE1jdIHur9ShmqbEsUMwia2lbefBgHFVl4N_9PbAPXW_9Zl-TP6v8PHPM9B_B61da-vVDZN6g4pm2cxnc59K5dmFtHJBPLajvXJA/s320/Screen+Shot+2013-10-07+at+11.14.19+AM.png" width="320" /></a></div>
<br />
The coordination layer would use whatever external APIs Fitbit and Nest made available in order to a) query my steps via the Fitbit cloud and b) send a directive to the nest via it's cloud to lower the temperature.<br />
<br />
Of course, the two different API calls would need to be authenticated as<br />
<br />
a) coming from a valid API client<br />
b) compatible with the user's preferences<br />
<br />
OAuth 2 satisfies both of the above requirements - giving to the user the ability to<br />
<br />
a) tell Fitbit what parties can see their step data<br />
b) tell Nest what parties can control the thermostat<br />
<br />
This sort of IFTTT-style coordination is a key value proposition of the emerging IoT platforms like Xively, Thingworx etc. Application developers can build on the platform, and need not worry about the specifics of how different devices integrated into to the platform, and be able leverage the resultant cross-device coordination capabilities. Of course (unless the platform scrape the login screens) Fitbit and Nest have to buy into the above scenario and actively allow 3rd party platforms to call their APIs (as opposed to only their own native applications).<br />
<br />
If the Fitbit & Nest business folks were to get together to 'do lunch' and agree that there was value for both in more directly working together, then a different (and arguably simpler, at least in the near term) integration is possible. This is shown below<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD8U_Jd6tkc49gNXgBs7HbovZMSoxXM7F5D-mlJb6aFsMvztSUzNxSwuOAgQqCGQv43zlu7AJMMEDh9zRYimF48Ym7RYjKQEVBi-vXhuLAtWAfWUq_PowSWr3t02xR1gDxK4PcLg/s1600/Screen+Shot+2013-10-07+at+11.32.17+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="313" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD8U_Jd6tkc49gNXgBs7HbovZMSoxXM7F5D-mlJb6aFsMvztSUzNxSwuOAgQqCGQv43zlu7AJMMEDh9zRYimF48Ym7RYjKQEVBi-vXhuLAtWAfWUq_PowSWr3t02xR1gDxK4PcLg/s320/Screen+Shot+2013-10-07+at+11.32.17+AM.png" width="320" /></a></div>
<br />
<br />
Here the user's step data is sent from Fitbit (not necessarily from the device itself, as shown) to Nest. It is at Nest that the rule 'drop temperature when steps equals 3000' was defined - Fitbit knows only that the user has authorized this integration - this consent manifested in the issuance of an OAuth access token from Nest to Fitbit. By including this access token on its API calls to Nest, Fitbit gives to Nest the information required to look up the user in their systems. The rules kicks in, and the Nest cloud directs the appropriate thermostat (mine not yours) to lower the temperature accordingly.<br />
<br />
<b>NB</b> This model is 'simpler' than the platform model above because there are only two services to coordinate (and so one less account for the user to manage). In the long run however, such pair-wise coordination won't scale well. What happens when I want a G&T ready on the counter when I walk into my comfortably cool house?<br />
<br />
Of course, beyond agreeing to use OAuth, Nest & Fitbit would also need to agree on the specifics of the API by which the step data was communicated. And while shown here as the step data being pushed from Fitbit to Nest (perhaps triggered by a subscription), it could be a pull from Nest, based on some polling schedule. <br />
<br />
The mirror image integration is also possible<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiymmz60ik57fCUadB-ITQZu9pRbGvjEXdKmVOc_3rnTuDGyFijSVLfCoJjoIld27p8-OMDb2HIdktPF3Ty4KPbJAL2lTHmDuUQu1PcdHdbqAggwuy7Krp2Y1zoZXeDM9g8oQwY1g/s1600/Screen+Shot+2013-10-07+at+11.41.15+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiymmz60ik57fCUadB-ITQZu9pRbGvjEXdKmVOc_3rnTuDGyFijSVLfCoJjoIld27p8-OMDb2HIdktPF3Ty4KPbJAL2lTHmDuUQu1PcdHdbqAggwuy7Krp2Y1zoZXeDM9g8oQwY1g/s320/Screen+Shot+2013-10-07+at+11.41.15+AM.png" width="312" /></a></div>
<br />
Here the coordination logic resides with Fitbit, and it is Nest that is relatively dumb. Nest would probably feel that there is a big difference between giving 'write' access to Fitbit, whereas in the previous scenario Fitbit needed only to give to Nest 'read' access. I guess the BD folks will work it over drinks at lunch.<br />
<br />
However architected, OAuth 2.0 stands to be a key enabler of multi-device coordination in the Internet of Things.<br />
<br />
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0tag:blogger.com,1999:blog-12447072.post-20338121050916765012013-06-12T11:43:00.001-04:002013-06-12T11:43:30.594-04:00Elvis-like, the data has left the buildingEnterprises want to ensure that its business data is accessed only by those who have a valid right to do so, ie those that require access in order to do their jobs. When the business data is only ever stored on a server, behind a web page or an API, restricting such access is relatively easy. Authenticate the user sending the request for the data, check their roles, determine if the roles are such that the user has a justifiable need to get at the data and, if so, approve the request and send the data back to the requesting client. (When the identity store (where the roles are kept) is remote from the business data (as is the case when the data is held by some SaaS), the mechanisms (and standardized protocols) might differ, but the logic remains the same).<br />
<br />
A client sends a request for the data - this request intercepted by some sort of enforcement mechanism (a Policy Enforcement Point (PEP) in the lingo). A co-located Policy Decision Point (PDP) determines which policy is relevant for the requested data, and interprets that policy to make a decision whether to grant the request or not. If the decision is 'yes', the data is served up back to the client (either as HTML or JSON depending on the nature of the client).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghWfgvzLctbbphFqgTthXazrOSSZb7Xn5fDIi8VYYlHdoogrH4k78LXyVYC65WlXLxFgViJzv7j6sFaAIvyxhZSsKPptj-ukThC4f5fayG9fV67KelWeiF7t3xxRr9J4yJdfgKcg/s1600/Screen+Shot+2013-06-12+at+7.07.06+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="140" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghWfgvzLctbbphFqgTthXazrOSSZb7Xn5fDIi8VYYlHdoogrH4k78LXyVYC65WlXLxFgViJzv7j6sFaAIvyxhZSsKPptj-ukThC4f5fayG9fV67KelWeiF7t3xxRr9J4yJdfgKcg/s320/Screen+Shot+2013-06-12+at+7.07.06+AM.png" width="320" /></a></div>
<br />
All good, but as soon as you allow the business data, once released by the server, to be stored by the requesting client beyond the original session, then the original access control check is no longer sufficient and must be supplemented. Despite the additional complexity, mobile native applications and enabling offline usage (the 'CEO sitting in seat 3B' use case) push the enterprise towards supporting this sort of client storage.<br />
<br />
The Mobile Information Management (MIM) proposition is that the business data delivered down to the clients (the native applications) carries with it (implicitly or explicitly) the policies governing its access & usage - reminiscent of DRM. Before the data is delivered down to the mobile client, appropriate policy is bound to the data - the policy will stipulate what users and/or applications can access the data, what they can do with it, and restrictions on subsequent sharing. Once on the device, only if the policy stipulations are met will the data be made accessible to particular applications, and what they subsequently do with that data will also be accordingly constrained.<br />
<br />
But merely attaching some rules to a document or powerpoint (PRISM anyone?) doesn't actually restrict access to that data. It would be a polite hacker that, seeing a rule forbidding her access, respected that rule. There needs to be a mechanism on the device comparable to the PEP in the diagram above to <i>enforce</i> the policy, ie prevent all data access unless the policy is met.<br />
<br />
You also need something comparable to the PDP to read & interpret the policy associated with a given piece of data. But whereas in the above model, the policy decision was whether or not to release the data itself, in this case the data has already been released, it's already on the client after all. So what is the decision?<br />
<br />
In MIM, the policy enforcement mechanism (the PEP that prevents unauthorized access) is appropriate encryption of the data, and the policy decision (made by the PDP determining what is authorized access) is whether or not to release a key that can be used to decrypt the data.<br />
<br />
An abstract model is shown below<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhKkrUI5f0qCeq5tVV6fM81iX1U93V9EjZZkkgPFKNY9CAJJvWVIB77gbMTyG16Bv7avwIfoMbpt3DoOht4hZclewrcgiGGbepWdjmblKrRwW9GKm3_Y29kCnowvE8DAUyjAWtWvw/s1600/Screen+Shot+2013-06-12+at+11.13.59+AM.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="393" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhKkrUI5f0qCeq5tVV6fM81iX1U93V9EjZZkkgPFKNY9CAJJvWVIB77gbMTyG16Bv7avwIfoMbpt3DoOht4hZclewrcgiGGbepWdjmblKrRwW9GKm3_Y29kCnowvE8DAUyjAWtWvw/s640/Screen+Shot+2013-06-12+at+11.13.59+AM.png" width="640" /></a></div>
<br />
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br />
<br />
<br />
<br />
<br />
<br />
On the right is some piece of business data, encrypted to prevent just anybody who has access to the device on which it sits from being able to access the data. On the left is a decryption key that will decrypt the encrypted data and so make it accessible to application usage. For an application to be able to 'get at' the data, it will need to gain access to the decryption key.<br />
<br />
Sitting between the two (the encrypted data and the corresponding decryption key) is the policy enforcement & decision infrastructure that ensures the two will 'meet' if and only if the policy is satisfied. Policy associated with the encrypted business data stipulates under which contexts the decryption key can be released, as well as additional constraints should that happen. Taken as input to the 'key release' decision are all the various current contexts, ie what app is trying to access the data, one behalf of which user, when, where etc.<br />
<br />
If the policy decision is 'yes', then the PEP releases the decryption key to the application, along with additional constraints (read but no right, no sharing etc). Now armed with the decryption key, the application uses it to decrypt the data and does whatever it does.<br />
<br />
The above is abstract, how to make it concrete? Specifically<br />
<br />
<ol>
<li>how is the policy bound to data?</li>
<li>how & where is the data encrypted?</li>
<li>with which key?</li>
<li>how & from where is the decryption key obtained? </li>
<li>how are PEP & PDP roles distributed? </li>
</ol>
<div>
Next time I'll propose an architecture for the above that leverages </div>
<div>
<ul>
<li>REST APIs</li>
<li>OAuth & OpenID Connect as mechanisms for authenticating & authorizing clients to such APIs</li>
</ul>
</div>
</div>
Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com2tag:blogger.com,1999:blog-12447072.post-33174684868969455632013-05-29T07:28:00.004-04:002013-05-29T07:28:56.211-04:00Discovery for IoTPremise is that the IoT would have us awash in services advertising us of their availability.<br />
<br />
So, how to filter this sea down to something useful & manageable?
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSMg5o9Oej5ZTzDvrMT4e7NzK6mEDtWXC5Cr4laWygj6D43uNVp719HKqRuOXxHsv7e_67pr6up1UdIWh0qGbSCuMq6MEf-0SjbDCWIEf610YSEff1S2W81yE2pdKUC5nddImaag/s1600/Screen+Shot+2013-05-29+at+7.22.25+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSMg5o9Oej5ZTzDvrMT4e7NzK6mEDtWXC5Cr4laWygj6D43uNVp719HKqRuOXxHsv7e_67pr6up1UdIWh0qGbSCuMq6MEf-0SjbDCWIEf610YSEff1S2W81yE2pdKUC5nddImaag/s400/Screen+Shot+2013-05-29+at+7.22.25+AM.png" width="382" /></a></div>
<br />
Via filters determined (mostly) by the context of everything else we have going on - what searches we've performed, what events are in our calendar, what we've recently bought, listened to etc etc.<br />
<br />
Those services that meet the criteria are allowed to prompt us (via applications?) for interaction.Paul Madsenhttp://www.blogger.com/profile/08489111023182783403noreply@blogger.com0