Hi Jeff, Totally agree! For me is UMA a good candidate for solving certain issues in the IoT. But in fact it is not really our job to decide yet about protocols in our DG (regarding our charter). Maybe later in a WG. Before we can do this we have to identify/analyze/sort out/discuss open issues and answer many other questions . Ingo From: j stollman [mailto:stollman.j@gmail.com] Sent: Samstag, 24. August 2013 15:26 To: Friese, Ingo Cc: Colin Wallis; emaler@forrester.com; dg-idot@kantarainitiative.org Subject: Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo The discussion of UMA gives me a bit of pause. I think UMA is a great concept and I am pleased and impressed with how it has developed from concept to early reality. But without derogating UMA, I wonder if the discussion of UMA is yet ripe in the IoT DG. The topic of the Internet of Things is quite broad. Under this single rubrick fall such issues as the following: 1. What devices will become internet enabled? 2. What new capabilities will arise from devices becoming internet enabled? 3. What are the concerns about using internet-enabled devices? * security * privacy * identity * legal 1. What are the mitigations for the above concerns? 2. How can this new ecosystem be managed? * at the individual level * at the ecosystem level 1. What technology/protocol solutions can be used to accommodate the management and mitigations? As a discussion group without deliverables, we are free to cover any and all of the topics above (plus those I overlooked). But I fear that if our small group tries to address all of them at once, we will fritter away our motivation. I support the idea of developing use cases, because they will likely inform all of issues above. But I am fearful of the discussion migrating too soon to the solution end of the spectrum before we have explored the depth and breadth of the issues that will evolve from our futurecasting which will lead eventually to defining requirements . As technologists jumping to solutions before we have fully articulated requirements is frequently our tendency. I am not arguing that UMA is not be applicable to IoT. But I am not certain that trying to devise solutions at this early stage won't cause us to create solution silos. If we articulate the first several requirements of IoT, stop developing requirements, and then determine that UMA solves the puzzle for this small segment of the market we defined, we create a narrow "standard" that may not address the other requirements which we later recognize. We can't wait forever to have the :"complete" list of requirements. But at this early state, I am wary of putting too much focus on any solution before we have invested significant energy into imagining the potential of this fascinating area of innovation and, by doing so, developing a more comprehensive set of its requirements. Thank you. Jeff On Fri, Aug 23, 2013 at 8:36 AM, mailto:Ingo.Friese@telekom.de> wrote: Hi Eve, Hi Colin, Without knowing all UMA details I have the feeling that UMA could work for many use-cases in the Internet of Things, e.g. in terms of authorization although the resource owner is not present; a standardized way to introduce the AM to the protected source; one AM per user/owner etc.. Ingo From: Eve Maler [mailto:eve@xmlgrrl.commailto:eve@xmlgrrl.com] Sent: Montag, 19. August 2013 17:55 To: Colin Wallis; Friese, Ingo; dg-idot@kantarainitiative.orgmailto:dg-idot@kantarainitiative.org Subject: Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo Hi folks-- Responding from my personal email address... "OAuth for things" and granting access authorization to autonomous (no pun intended) third parties around access to devices are topics we've discussed a bit in the UMA group. You can see the discussion in our 2013-06-20 meeting noteshttp://kantarainitiative.org/confluence/display/uma/UMA+telecon+2013-06-20 and also in the "Device Managed Access" email threadhttp://kantarainitiative.org/pipermail/wg-uma/2013-June/thread.html. What UMA's profile adds to OAuth's typical capabilities (wrt this topic, anyway) is to allow the resource owner to set the conditions of access ("policy") and then not have to be present or logged in to anything when a third-party requesting party comes along and attempts access. The choice of whether to treat a human being or the "thing" itself as the initial resource owner is an interesting philosophical/deployment-specific question. Eve On 19 Aug 2013, at 8:15 AM, "Maler, Eve" mailto:emaler@forrester.com> wrote: Eve Maler Forrester Research | Principal Analyst, Security & Risk | cell +1 425.345.6756tel:%2B1%20425.345.6756 | @xmlgrrl | forr.com/evemalerhttp://forr.com/evemaler ---------- Forwarded message ---------- From: Colin Wallis mailto:colin_wallis@hotmail.com> Date: Thu, Aug 15, 2013 at 6:29 PM Subject: RE: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo To: "Ingo.Friese@telekom.demailto:Ingo.Friese@telekom.de" mailto:ingo.friese@telekom.de>, "dg-idot@kantarainitiative.orgmailto:dg-idot@kantarainitiative.org" mailto:dg-idot@kantarainitiative.org>, Eve Maler mailto:emaler@forrester.com> Very very good use case Ingo. I can see why you cannot discuss Security and Privacy because there is no Authn or Authz baseline to build considerations for these. I went back to your links to the IETF work in your previous emails where I remember Authn and Authz mentioned. Not much there! More questions than anything.. But CoAP over DTLs/TLs was mentioned. ...and questions on whether OAuth could be refashioned into 'SASL and the GSS-API' ..which I guess is another way of getting to the same place you are suggesting with UMA (cc'ing Eve in here for a comment..) Cheers Colin ________________________________ From: Ingo.Friese@telekom.demailto:Ingo.Friese@telekom.de To: dg-idot@kantarainitiative.orgmailto:dg-idot@kantarainitiative.org Date: Thu, 15 Aug 2013 15:06:09 +0200 Subject: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo Dear all, Please find attached my first draft for one of my IDoT use-cases. Thoughts and comments are highly welcome. Ingo http://kantarainitiative.org/confluence/display/IDoT/Use+Case+Repository Scenario "Enhanced car mobility" draft (Ingo Friese) Intro A rental car company "Green&Blue cars"wants to sell mobility instead of just renting cars per hour/day. They want to start a new business: selling mobility. A customer buys mobility e.g. for three days. Everything is included e.g. fees for the parking houses (owned by a company "Berlin Parking") and costs for gas or energy taken from energy-stations (owned by a company "Berlin Green Energy"). Scenario Bob visits the city of Berlin. He goes to the counter of "Green&Blue cars" and buys 3 days of mobility. He signs the contract and gets the key for the car. Now he is driving through the city center and wants to stop for sightseeing. He drives to a "Berlin Parking" house. When he wants to leave the parking house after a while a sensor at the gate recognizes and authenticates the identity of his rental car. As both companies "Green&Blue cars" and "Berlin Parking" have some mutual agreement the gate opens. Bob recognizes that the battery of his car is low. The navigation system directs him to a "Berlin Green Energy" Station. When he arrives at the energy station his car is identitfied and authenticated. Bob loads the battery without any payment and goes on. More technical view

From the identity point of view we have several aspects here:

Bob is crossing domains of different companies. All these companies may have chosen different solutions, protocols and address and authentication schemes to manage their items. Addressing/Discovery The gate of "Berlin Parking" has to communicate with Bob's car. At least in order to recognize "ok this car has a special contract so it's good to go". For communication we need communication endpoints/addresses for the gate and for the car. The endpoint for the gate could be: 10.0.0.78.88.9876.berlincenter.berlinparking.dehttp://10.0.0.78.88.9876.berlincenter.berlinparking.de/ (mixed address...public & "Berlin Parking" specific address URL) The endpoint for the car is in fact an IMEI (International Mobile Station Equipment Identity) of a mobile build in GSM unit e.g. #490154203237518#. Other rental car companies use the car-id taken from the CAN-BUS System (widely used system in car industry). Both companies have their special address scheme. How to address items across different domains, namespaces and formats? (Extensible Resource Identifier OASIS XRI might be an approach....needs further discussion) Authentication Bob is able to load the battery of his car or he can get gasoline without direct payment. It is really important that only cars of "Green&blue car" company get their fuel or energy without extra payment. So the car has to authenticate itself against the energy station. How to provide authentication without Bob's interaction? May be its possible to find a special solution for "Green&blue car" but what if tomorrow other rental car companies want to join? Is there something like a general authentication scheme for things? Authorization "Green&blue car" is only allowed for gas up to a certain amount of money. How to authorize things? (OAuth for Things?...) Policies The rental car company "Green&blue car" is allowed to check the status, location and certain statistics at any time. "Berlin Green Energy" is allowed to check the location of Bobs car in order to direct him to the nearest Energy station. There has to be a policy management deciding who is allowed for what? I have the feeling we need an authorization framework here. (kind of UMA/OAuth thing?) _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.orgmailto:DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756tel:%2B1%20425%20345%206756 http://www.twitter.com/xmlgrrl _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.orgmailto:DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot -- Jeff Stollman stollman.j@gmail.commailto:stollman.j@gmail.com 1 202.683.8699 Truth never triumphs - its opponents just die out. Science advances one funeral at a time. Max Planck