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.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?)
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.de To: 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.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.org http://kantarainitiative.org/mailman/listinfo/dg-idot
Very interesting use case Ingo. In fact, not that different from that is use by ZipCars in the US at the moment. If you wish I would be happy to give a quick comparison of ZipCars and your Use Case Allan Simplify Email: Email Charter <http://emailcharter.org/> *Allan Foster - ForgeRock * /Vice President - ForgeRock.org/ *Office of the CTO* *Location:* Vancouver, WA, US *e:* allan.foster@forgerock.com <mailto:allan.foster@forgerock.com> *w:* www.forgerock.org <http://www.forgerock.org/> *b:* blogs.forgerock.com/GuruAllan <http://blogs.forgerock.com/GuruAllan> On 8/15/13 6:06 AM, Ingo.Friese@telekom.de wrote:
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.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.org http://kantarainitiative.org/mailman/listinfo/dg-idot
Hi Allan, Great! A comparison/cross-check with a "real world" use case would be valuable. Ingo From: dg-idot-bounces@kantarainitiative.org [mailto:dg-idot-bounces@kantarainitiative.org] On Behalf Of Allan Foster Sent: Freitag, 16. August 2013 06:29 To: dg-idot@kantarainitiative.org Subject: Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo Very interesting use case Ingo. In fact, not that different from that is use by ZipCars in the US at the moment. If you wish I would be happy to give a quick comparison of ZipCars and your Use Case Allan Simplify Email: Email Charter<http://emailcharter.org/> Allan Foster - ForgeRock Vice President - ForgeRock.org Office of the CTO Location: Vancouver, WA, US e: allan.foster@forgerock.com<mailto:allan.foster@forgerock.com> w: www.forgerock.org<http://www.forgerock.org/> b: blogs.forgerock.com/GuruAllan<http://blogs.forgerock.com/GuruAllan> On 8/15/13 6:06 AM, Ingo.Friese@telekom.de<mailto:Ingo.Friese@telekom.de> wrote: 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.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.org<mailto:DG-IDoT@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-idot
I am confused about the value of Ingo's care use case. There is a current solution to this problem in use in the US. It is called EZ-Pass. A user attaches an RFID tag to his vehicle. Interrogators located at toll booths along toll roads and bridges interrogate devices as they pass by and debit the account. There are separate lanes at the toll station for cars without EZ-Pass. (They also take a photograph of the car and driver to catch those who pass through the EZ-Pass toll gate without the RFID tag and to avoid repudiation of charges by those who have EZ-Pass but later deny such charges.) Different service providers (in this case state toll road commission) sign up for the service and agree to use the RFID protocol of the EZ-Pass provider. This is not really an IoT solution. It is a bit clumsy because it requires an additional device versus leveraging identity capabilities built in to the car. But I would imagine that if the auto industry standardized on an identity technology, the problem is simple. Berlin Parking would merely use the comms protocol established by the auto makers to identify the vehicle. They would then look up the vehicle in their database to see if it is one of their direct parking clients. If not, they would then proceed to perform a lookup in the database for Green&Blue Cars. If they find the car listed, they let it through. If not, the gate stays down until they proffer some alternative method of payment, e.g., pushing a button to obtain a time-stamped ticket of their entry time. Berlin Parking might also take a photograph to avoid later repudiation. The point is that I am not sure that Auth'n is more than a simple vehicle identity and Auth'z a simple database lookup. The complexity comes only from waiting for a comms standard to emerge. Am I missing something? Thank you. Jeff On Mon, Aug 19, 2013 at 4:41 AM, <Ingo.Friese@telekom.de> wrote:
Hi Allan,****
** **
Great! A comparison/cross-check with a “real world” use case would be valuable.****
** **
Ingo****
** **
*From:* dg-idot-bounces@kantarainitiative.org [mailto: dg-idot-bounces@kantarainitiative.org] *On Behalf Of *Allan Foster *Sent:* Freitag, 16. August 2013 06:29 *To:* dg-idot@kantarainitiative.org *Subject:* Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo****
** **
Very interesting use case Ingo.
In fact, not that different from that is use by ZipCars in the US at the moment. If you wish I would be happy to give a quick comparison of ZipCars and your Use Case
Allan****
Simplify Email: Email Charter <http://emailcharter.org/>
*Allan **Foster** - Forge**Rock * *Vice President - ForgeRock.org* *Office of the CTO* *Location:* Vancouver, WA, US *e:* allan.foster@forgerock.com *w:* www.forgerock.org *b:* blogs.forgerock.com/GuruAllan****
On 8/15/13 6:06 AM, Ingo.Friese@telekom.de wrote:****
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.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.org****
http://kantarainitiative.org/mailman/listinfo/dg-idot****
** **
_______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot
-- Jeff Stollman 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
Hi Jeff, Of course there many individual solutions. EZ-pass is already there and it works. But this is not the point. The question is. Can expand this use-case very easily? (you are right maybe this becomes not that clear in my description) For example: When a car is running out of energy the nearby energy station say "ok I have a free plug...and I'll make a reservation for you for 30min starting in 10 minutes" For contacting the car somewhere on a road a RFID chip helps not much (just to stay with your example) Here we have currently another solution (e.g. using a GSM module). Infact we have RFID chips for problem 1 and GSM for problem 2. In best case we find an architecture for both toll gates and information exchange, based on web technologies because its flexible, loosely coupled, scalable and lightweight. Thoughts? From: j stollman [mailto:stollman.j@gmail.com] Sent: Montag, 19. August 2013 14:24 To: Friese, Ingo Cc: allan.foster@forgerock.com; dg-idot@kantarainitiative.org Subject: Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo I am confused about the value of Ingo's care use case. There is a current solution to this problem in use in the US. It is called EZ-Pass. A user attaches an RFID tag to his vehicle. Interrogators located at toll booths along toll roads and bridges interrogate devices as they pass by and debit the account. There are separate lanes at the toll station for cars without EZ-Pass. (They also take a photograph of the car and driver to catch those who pass through the EZ-Pass toll gate without the RFID tag and to avoid repudiation of charges by those who have EZ-Pass but later deny such charges.) Different service providers (in this case state toll road commission) sign up for the service and agree to use the RFID protocol of the EZ-Pass provider. This is not really an IoT solution. It is a bit clumsy because it requires an additional device versus leveraging identity capabilities built in to the car. But I would imagine that if the auto industry standardized on an identity technology, the problem is simple. Berlin Parking would merely use the comms protocol established by the auto makers to identify the vehicle. They would then look up the vehicle in their database to see if it is one of their direct parking clients. If not, they would then proceed to perform a lookup in the database for Green&Blue Cars. If they find the car listed, they let it through. If not, the gate stays down until they proffer some alternative method of payment, e.g., pushing a button to obtain a time-stamped ticket of their entry time. Berlin Parking might also take a photograph to avoid later repudiation. The point is that I am not sure that Auth'n is more than a simple vehicle identity and Auth'z a simple database lookup. The complexity comes only from waiting for a comms standard to emerge. Am I missing something? Thank you. Jeff On Mon, Aug 19, 2013 at 4:41 AM, <Ingo.Friese@telekom.de<mailto:Ingo.Friese@telekom.de>> wrote: Hi Allan, Great! A comparison/cross-check with a "real world" use case would be valuable. Ingo From: dg-idot-bounces@kantarainitiative.org<mailto:dg-idot-bounces@kantarainitiative.org> [mailto:dg-idot-bounces@kantarainitiative.org<mailto:dg-idot-bounces@kantarainitiative.org>] On Behalf Of Allan Foster Sent: Freitag, 16. August 2013 06:29 To: dg-idot@kantarainitiative.org<mailto:dg-idot@kantarainitiative.org> Subject: Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo Very interesting use case Ingo. In fact, not that different from that is use by ZipCars in the US at the moment. If you wish I would be happy to give a quick comparison of ZipCars and your Use Case Allan Simplify Email: Email Charter<http://emailcharter.org/> Allan Foster - ForgeRock Vice President - ForgeRock.org Office of the CTO Location: Vancouver, WA, US e: allan.foster@forgerock.com<mailto:allan.foster@forgerock.com> w: www.forgerock.org<http://www.forgerock.org/> b: blogs.forgerock.com/GuruAllan<http://blogs.forgerock.com/GuruAllan> On 8/15/13 6:06 AM, Ingo.Friese@telekom.de<mailto:Ingo.Friese@telekom.de> wrote: 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.de<http://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.org<mailto:DG-IDoT@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-idot _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org<mailto:DG-IDoT@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-idot -- Jeff Stollman stollman.j@gmail.com<mailto: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
Jeff, If you look at EZ Pass it is still the case that their transponders (credentials) cannot be federated with SunPass (FL) or FastTrak (CA), etc. so there is way to go for device interoperability even though you do have open road payments (you don't really need those booths) and users still can't apply the transponder to other vehicle, e.g. parking use cases. Chipped trucks (digital tachymeters) are an example of tighter binding of identifier to device along the lines of a device LOA. ZipCar is another good use case for credential (lower assurance than the smart card in the tachymeter, it's low symmetric key). These are use case where you have people (plural and large numbers) identity, identifiers, attributes (owner, driver among others), and the devices (ditto many) and network (roads). So yes in some cases the things built with technology from decades ago are simple. That notwithstanding there are a wide range of intelligent vehicle activities underway global to leverage the vehicle and device tech. In order to do this a wide range of challenges and questions but at the same time consider navigation and route guidance advances in the last decade, it's the to point where the hard part is take over from the driver. Talk about delegated control. Nothing simple here. I think there is good ground here (see below outing my bias). And at this point might we think there are no bad use cases yet. Cheers, Sal PS, used to Chair the oxymoron of the Intelligent Transportation Society of Massachusetts 15 years ago and spent some time putting sensors and data acquisition systems including RFID and video in transport including some of the above. There are a lot of different options look at this today. From: dg-idot-bounces@kantarainitiative.org [mailto:dg-idot-bounces@kantarainitiative.org] On Behalf Of j stollman Sent: Monday, August 19, 2013 8:24 AM To: Ingo.Friese@telekom.de Cc: dg-idot@kantarainitiative.org Subject: Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo I am confused about the value of Ingo's care use case. There is a current solution to this problem in use in the US. It is called EZ-Pass. A user attaches an RFID tag to his vehicle. Interrogators located at toll booths along toll roads and bridges interrogate devices as they pass by and debit the account. There are separate lanes at the toll station for cars without EZ-Pass. (They also take a photograph of the car and driver to catch those who pass through the EZ-Pass toll gate without the RFID tag and to avoid repudiation of charges by those who have EZ-Pass but later deny such charges.) Different service providers (in this case state toll road commission) sign up for the service and agree to use the RFID protocol of the EZ-Pass provider. This is not really an IoT solution. It is a bit clumsy because it requires an additional device versus leveraging identity capabilities built in to the car. But I would imagine that if the auto industry standardized on an identity technology, the problem is simple. Berlin Parking would merely use the comms protocol established by the auto makers to identify the vehicle. They would then look up the vehicle in their database to see if it is one of their direct parking clients. If not, they would then proceed to perform a lookup in the database for Green&Blue Cars. If they find the car listed, they let it through. If not, the gate stays down until they proffer some alternative method of payment, e.g., pushing a button to obtain a time-stamped ticket of their entry time. Berlin Parking might also take a photograph to avoid later repudiation. The point is that I am not sure that Auth'n is more than a simple vehicle identity and Auth'z a simple database lookup. The complexity comes only from waiting for a comms standard to emerge. Am I missing something? Thank you. Jeff On Mon, Aug 19, 2013 at 4:41 AM, <Ingo.Friese@telekom.de> wrote: Hi Allan, Great! A comparison/cross-check with a "real world" use case would be valuable. Ingo From: dg-idot-bounces@kantarainitiative.org [mailto:dg-idot-bounces@kantarainitiative.org] On Behalf Of Allan Foster Sent: Freitag, 16. August 2013 06:29 To: dg-idot@kantarainitiative.org Subject: Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo Very interesting use case Ingo. In fact, not that different from that is use by ZipCars in the US at the moment. If you wish I would be happy to give a quick comparison of ZipCars and your Use Case Allan Simplify Email: Email Charter <http://emailcharter.org/> Allan Foster - ForgeRock Vice President - ForgeRock.org Office of the CTO Location: Vancouver, WA, US e: allan.foster@forgerock.com w: www.forgerock.org <http://www.forgerock.org/> b: blogs.forgerock.com/GuruAllan On 8/15/13 6:06 AM, Ingo.Friese@telekom.de wrote: 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.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.org http://kantarainitiative.org/mailman/listinfo/dg-idot _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot -- Jeff Stollman 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
All, I seem not to have made my point very clearly. I was not suggesting that EZ Pass is the solution. I was merely using it to point out that as initially stated, Ingo's use case required only the ability to uniquely identify a vehicle. No other data need be exchanged between the vehicle and the parking or energy stations. Ingo's more recent variant (reserving a spot at the plug to recharge) is more interesting because it requires.a more sophisticated conversation between the vehicle and the recharge station, and does not require RFID-like proximity. Sorry for the confusion. Jeff On Mon, Aug 19, 2013 at 9:27 AM, Salvatore D'Agostino <sal@idmachines.com>wrote:
Jeff,****
** **
If you look at EZ Pass it is still the case that their transponders (credentials) cannot be federated with SunPass (FL) or FastTrak (CA), etc. so there is way to go for device interoperability even though you do have open road payments (you don’t really need those booths) and users still can’t apply the transponder to other vehicle, e.g. parking use cases. Chipped trucks (digital tachymeters) are an example of tighter binding of identifier to device along the lines of a device LOA. ZipCar is another good use case for credential (lower assurance than the smart card in the tachymeter, it’s low symmetric key). These are use case where you have people (plural and large numbers) identity, identifiers, attributes (owner, driver among others), and the devices (ditto many) and network (roads). So yes in some cases the things built with technology from decades ago are simple.****
** **
That notwithstanding there are a wide range of intelligent vehicle activities underway global to leverage the vehicle and device tech. In order to do this a wide range of challenges and questions but at the same time consider navigation and route guidance advances in the last decade, it’s the to point where the hard part is take over from the driver. Talk about delegated control. Nothing simple here. I think there is good ground here (see below outing my bias). And at this point might we think there are no bad use cases yet…****
** **
** **
Cheers,****
** **
Sal****
** **
PS, used to Chair the oxymoron of the Intelligent Transportation Society of Massachusetts 15 years ago and spent some time putting sensors and data acquisition systems including RFID and video in transport including some of the above. There are a lot of different options look at this today.****
** **
*From:* dg-idot-bounces@kantarainitiative.org [mailto: dg-idot-bounces@kantarainitiative.org] *On Behalf Of *j stollman *Sent:* Monday, August 19, 2013 8:24 AM *To:* Ingo.Friese@telekom.de *Cc:* dg-idot@kantarainitiative.org
*Subject:* Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo****
** **
I am confused about the value of Ingo's care use case.****
** **
There is a current solution to this problem in use in the US. It is called EZ-Pass. A user attaches an RFID tag to his vehicle. Interrogators located at toll booths along toll roads and bridges interrogate devices as they pass by and debit the account. There are separate lanes at the toll station for cars without EZ-Pass. (They also take a photograph of the car and driver to catch those who pass through the EZ-Pass toll gate without the RFID tag and to avoid repudiation of charges by those who have EZ-Pass but later deny such charges.) Different service providers (in this case state toll road commission) sign up for the service and agree to use the RFID protocol of the EZ-Pass provider. ****
** **
This is not really an IoT solution. It is a bit clumsy because it requires an additional device versus leveraging identity capabilities built in to the car. But I would imagine that if the auto industry standardized on an identity technology, the problem is simple. Berlin Parking would merely use the comms protocol established by the auto makers to identify the vehicle. They would then look up the vehicle in their database to see if it is one of their direct parking clients. If not, they would then proceed to perform a lookup in the database for Green&Blue Cars. If they find the car listed, they let it through. If not, the gate stays down until they proffer some alternative method of payment, e.g., pushing a button to obtain a time-stamped ticket of their entry time. Berlin Parking might also take a photograph to avoid later repudiation.****
** **
The point is that I am not sure that Auth'n is more than a simple vehicle identity and Auth'z a simple database lookup. The complexity comes only from waiting for a comms standard to emerge.****
** **
Am I missing something?****
** **
Thank you.****
** **
Jeff****
** **
On Mon, Aug 19, 2013 at 4:41 AM, <Ingo.Friese@telekom.de> wrote:****
Hi Allan,****
****
Great! A comparison/cross-check with a “real world” use case would be valuable.****
****
Ingo****
****
*From:* dg-idot-bounces@kantarainitiative.org [mailto: dg-idot-bounces@kantarainitiative.org] *On Behalf Of *Allan Foster *Sent:* Freitag, 16. August 2013 06:29 *To:* dg-idot@kantarainitiative.org *Subject:* Re: [DG-IDoT] IDoT use-case collection "rental car mobility" scenario by Ingo****
****
Very interesting use case Ingo.
In fact, not that different from that is use by ZipCars in the US at the moment. If you wish I would be happy to give a quick comparison of ZipCars and your Use Case
Allan****
Simplify Email: Email Charter <http://emailcharter.org/>
*Allan Foster - ForgeRock * *Vice President - ForgeRock.org* *Office of the CTO* *Location:* Vancouver, WA, US *e:* allan.foster@forgerock.com *w:* www.forgerock.org *b:* blogs.forgerock.com/GuruAllan****
On 8/15/13 6:06 AM, Ingo.Friese@telekom.de wrote:****
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.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.org****
http://kantarainitiative.org/mailman/listinfo/dg-idot****
****
_______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot****
****
** **
-- Jeff Stollman 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****
-- Jeff Stollman 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
participants (5)
-
Allan Foster -
Colin Wallis -
Ingo.Friese＠telekom.de -
j stollman -
Salvatore D'Agostino