Cidades Inteligentes
Transporte: tem uma inovação dando certo ali em Cachoeirinha; o ônibus por aplicativo e a chance de virar tendência metropolitana
Leia mais »
18 de abril de 2024
Os mitos da cota única MAAS
Como usar padrões de identificação e autorização para atender às expectativas do MaaS
Edouard Bavoux
- 7 fevereiro 2024
O MaaS (Mobility-As-A-Service) é um conjunto de promessas, muitas vezes mitos, que merecem ser decifrados:
- Uma única aplicação para acessar os serviços de mobilidade de um conjunto de MSPs -Provedores de Serviços de Mobilidade (Mobility-Service-Provider).
- A oferta de VTCs, Uber, patinetes, trens, DRT em uma única conta de usuário para esses serviços, um único meio de pagamento, a compra de ofertas intermodais etc.
Conta Única de Mobilidade
Fornecedores de tecnologia costumam tratar a conta integrada de mobilidade, associada a uma série de informações tais como as preferências do usuário em termos de mobilidade, seu histórico de viagens, suas reservas ou produtos de mobilidade, como sinônimo do conceito de MaaS.
Na verdade, falamos aqui de Conta de Usuário, em sua visão mais restrita: uma forma de troca entre dois sistemas, sobre o mesmo usuário. É uma questão fundamental, plataformas MaaS e MSP – Provedores de Serviços de Mobilidade precisam ser capazes de trocar informações sobre o mesmo usuário. Todo o resto deriva desta funcionalidade.
Compartilhamento dos dados do usuário...
Para dizermos que há uma conta única, o cliente deve, por exemplo, conseguir desbloquear uma bicicleta ou scooter compartilhada com um aplicativo MaaS e ao final da corrida, usar o aplicativo do provedor de micro mobilidade compartilhada para encerrá-la. Se quiser acompanhar sua jornada, vai conseguir fazê-lo apenas na conta do provedor de micro mobilidade, não no aplicativo integrador, que tem a conta do usuário.
Um MSP – Provedor de serviço de mobilidade pode estar em mais de uma plataforma MaaS e como resultado, embora toda plataforma MaaS tenha a ambição de oferecer uma “única conta de mobilidade”, não é factível que um MSP use diretamente a base de usuários de um MaaS como seu próprio repositório.
Para definirmos a responsabilidade no gerenciamento de usuários é imperativo definir se o MaaS é mesmo um serviço real que o cliente assina ou é um simples intermediário de outros serviços.
- Mais: Conheça os serviços da OPTAI clicando aqui
A ideia deste texto é discutir soluções e questões técnicas relacionadas a essa escolha.
Existem várias alternativas para permitir que uma plataforma MaaS e um MSP se refiram a um mesmo cliente:
- Duplicando contas dos MSP
- Compartilhamento contas de MSP
- Sem conta de MSP
Modelo 1: Duplicando contas MSP (ou conta técnica)
O MSP separa os dados do usuário dedicados a cada plataforma MaaS. Compartimenta seus próprios usuários entre os que se relacionam ou não com uma plataforma MaaS. Como cada um desses “conjuntos” está em localizações independentes, não há problema de consistência.
A principal desvantagem é que a experiência do usuário é prejudicada, ao ter que mudar para a conta do MSP, uma vez que suas contas não estão correlacionadas.
Ilustração: Duplicação de conta de usuário: duas contas para Bob no sistema MSP
E essa é a razão de o cliente ter duas contas de mobilidade: a conta do aplicativo provedor do serviço e a conta “técnica” do mesmo serviço criada para você pelo aplicativo MaaS, após seu consentimento.
Este modelo tem a imensa vantagem de funcionar, ser simples e já configurado por um conjunto de MSPs, e alguns operadores de MaaS. Tecnicamente é muito simples: a plataforma MaaS e o MSP se comunicam, de servidor para servidor, de forma segura: chave API e HTTPS são o mínimo necessário, e outras soluções adicionais permitem ainda mais segurança, como assinatura de mensagens com chave assimétrica.
Em geral, é a plataforma MaaS que impulsiona a criação/exclusão das contas técnicas do usuário no sistema do MSP, de forma mais ou menos transparente para o usuário e, uma vez que o usuário não tem acesso a esta conta técnica a não ser através desta plataforma MaaS, não há informações de autenticação confidenciais, nenhuma senha pessoal, nada que exija uma solução avançada.
Quanto à responsabilidade e tratamento de dados pessoais, a plataforma MaaS é responsável pelos usuários: Gerenciamento de contas falsas, duplicatas, validação de números de telefone, e-mails etc. Ela manipula as contas técnicas dos vários MSPs, fornece apenas as informações necessárias para os serviços dos MSPs e pede explicitamente o consentimento do usuário para compartilhar seus dados.
O único problema é que ele não cumpre a promessa de uma única conta. Um cliente, na verdade, acaba tendo várias contas para o mesmo serviço de mobilidade. Sendo assim, não é permitido ao usuário alternar entre aplicativos (de MaaS para MSP), e isto impede que as plataformas MSP e MaaS realizem uma análise de uso aprofundada e garanta a exclusividade dos usuários do serviço, quando necessário (por exemplo, para evitar fraudes na utilização).
Modelo 2: Compartilhamento de conta MSP (ou vinculação de conta)
O MSP mantém o armazenamento de dados de usuários único, independentemente da plataforma usada para acessar os serviços de mobilidade. Como o MaaS ainda não dispõe de referências únicas e consolidadas, cada operador de MaaS pode querer processos específicos para sua plataforma. O mesmo usuário do sistema MSP pode ser afetado por cada um desses MaaS trazendo alto risco de inconsistências.
Ilustração: Compartilhando a conta de usuário MSP de Bob
Essa solução é mais complexa, ambiciosa e menos madura. Existem três fontes principais de dificuldade em configurá-lo (tanto para plataformas MaaS quanto para MSPs):
- Integração técnica de gerenciamento de usuários e autenticação MSP.
O MSP é responsável por seus usuários e isso não é mais delegado ao MaaS que deseja integrar este serviço. Como são os mesmos usuários, delegar a gestão ao MaaS seria uma fonte de confusão, inconsistência nos processos implementados na gestão de usuários, e a responsabilidade de oferecer o serviço ao usuário seria dividida entre os diferentes integradores, o que não é desejável. Como consequência, há diversas dificuldades técnicas para proteger os processos de vincular uma conta MSP a uma plataforma MaaS, gerenciar os túneis de registro MSP, às vezes complexos, e gerenciar a senha confidencial do usuário para esse serviço.
- Manter a consistência da solução.
Para uma plataforma MaaS “modelo” que integra um serviço de pagamento MaaS e um sistema de descontos, ou subsídios, consideremos um teste rápido sobre a consistência do compartilhamento de conta MSP:
Como cliente, “Bob” reserva um carro compartilhado através do seu aplicativo MaaS e durante o período de utilização do serviço, deseja estender o aluguel ou adicionar uma opção. Deve então encontrar seu serviço atual no aplicativo de compartilhamento de carros MSP (Viva o compartilhamento de conta MSP!) e fazer alterações. As vantagens oferecidas pelo serviço MaaS são válidas no seu aplicativo de carsharing, ou apenas no aplicativo MaaS? Você vai garantir benefícios em ambas as plataformas?
Essas são perguntas que precisam ser respondidas e implementadas nos sistemas do MSP e nas diversas plataformas MaaS, para manter a consistência.
Manter a consistência da solução, só é possível quando o pagamento, a avaliação (o fato de calcular o preço de um serviço de mobilidade) ou as regras de negócio são delegadas às plataformas MaaS.
- A ligação poderia ser uma via de mão dupla.
Por que não vincular também a conta MaaS no aplicativo MSP, além do contrário? Isso permitiria o acesso aos serviços MaaS (tarifas, produtos intermodais) a partir da plataforma do MSP. Esta é a direção oferecida pelas plataformas que desejam promover o uso de seus aplicativos móveis, permitindo que o usuário se beneficie das vantagens oferecidas pelos produtos MaaS.
Além desses 3 desafios, essa solução dificulta a experiência do usuário de MaaS e subjuga o serviço MaaS aos serviços fornecidos por MSPs.
Modelo 3: Nenhuma conta MSP
O MSP não tem armazenamento de dados do usuário. Ele considera a plataforma MaaS como seu cliente e não tem um sistema de gerenciamento de usuário final refinado. Um bom exemplo é o de uma estação de táxi. Do seu ponto de vista, a plataforma MaaS fez 178 viagens este mês. Apenas a plataforma MaaS consolida o vínculo entre os modos de deslocamento e os usuários.
Ilustração: Nenhuma conta de usuário para Bob no sistema MSP.
Conclusão
A solução de compartilhamento de contas MSP entre plataformas (modelo 2) só está madura, hoje, em contextos de plataforma MaaS “light”, sem delegação de pagamento e sem lógica MaaS. E para estes casos é a solução preferida.
Para uma plataforma MaaS completa com integração profunda, pagamento unificado e lógica de negócios limpa: é necessário ser capaz de lidar com os casos dos modelos 1 (duplicação de contas MSP) e 3 (ausência de contas MSP). Por outro lado, podemos nos questionar sobre a relevância do modelo 2 (MSP account sharing), independentemente de sua falta de maturidade.
Esse modelo adiciona atrito à experiência de MaaS no momento da criação e vinculação da conta, e não atende a um dos objetivos do MaaS: oferecer um serviço real para o usuário final, que pode então colocar as marcas comerciais dos MSPs em segundo plano, após a contextualização da oferta, qual seja:
– Opções mais próximas
– Serviço Mais rápido
– Menor impacto ambiental
– Mais barato
Dessa forma, o gerenciamento do Modelo 2 no contexto de uma plataforma MaaS completa não nos parece verdadeiramente relevante, no contexto atual.
LES MYTHES DU COMPTE UNIQUE MAAS
Comment utiliser les standards d’identification et d’autorisation pour répondre aux attentes du MaaS
Edouard Bavoux
Le MaaS (Mobility-As-A-Service) est un ensemble de promesses, parfois des mythes, qui méritent d’être décryptées :
- Une application unique pour accéder aux services de mobilité d’un ensemble de MSP (Mobility-Service-Provider : Imaginez les VTC Uber, les trottinettes Lime, la RATP, Vélib ou encore Blablacar).
- Un Compte Utilisateur unique pour ces services, un moyen de paiement unique, l’achat d’offres intermodales…
Aujourd’hui : Focus sur le “Compte Unique de Mobilité”.
Les acteurs du MaaS parlent de “Compte de mobilité”, parfois comme synonyme au concept du MaaS, ou bien associé à de nombreuses informations : Les préférences de l’utilisateur en matière de mobilité, ses historiques de trajets quel que soit l’opérateur de mobilité utilisé, ses réservations ou produits mobilité.
Mais je parle ici du compte utilisateur, dans sa vision la plus réduite : un moyen d’échanger entre deux systèmes, à propos d’un même utilisateur. Cette notion de compte utilisateur est clé. Une plateforme MaaS et un MSP doivent pouvoir échanger à propos d’un même utilisateur. Tout le reste en découle : S’ils peuvent échanger à propos d’un même utilisateur, ils peuvent se tenir informés de ses achats, de ses préférences mises à jour, de ses trajets effectués, etc.
Le Partage du référentiel utilisateur…
… est la notion clé.
Un petit test sur la promesse du Compte unique:
En tant que voyageur, Bob: Vous débloquez une trottinette Lime avec une application MaaS. En fin de course, vous ouvrez l’application Lime pour terminer la course :
Vous vous attendez sûrement à voir votre trajet en cours, mais ce n’est pas le cas : Vous avez maintenant deux comptes Lime, et la course de trottinette est uniquement en cours pour votre compte Lime du MaaS. On se sent mieux n’est-ce pas ? On inspire à fond, on expire, tout va bien.
Un MSP donné peut participer à plusieurs MaaS. En conséquence : Bien que chaque plateforme MaaS ait l’ambition de proposer un “compte de mobilité unique”, il est impensable qu’un MSP utilise directement la base utilisateur d’un MaaS comme étant son propre référentiel.
Si l’on s’éloigne de ce constat logique, et de la tech, c’est évident qu’il faut définir les responsabilités de la gestion utilisateur : Le MaaS est il un vrai service auquel l’utilisateur souscrit, ou bien un simple intermédiaire ?
L’idée de cet article est de se pencher sur les solutions et problématiques techniques liées à ce choix. Volontairement, les autres aspects de la question, (juridiques, stratégiques,…), ne sont pas développés ici.
Il existe plusieurs alternatives, pour permettre à une plateforme MaaS et un MSP d’échanger à propos d’un même voyageur:
- Duplication des comptes MSP
- Partage de compte MSP
- Absence de compte MSP
Modèle 1 : Duplication des comptes MSP (ou compte technique)
Le MSP sépare ses référentiels utilisateurs pour chaque MaaS. Il sépare également son référentiel d’utilisateurs propre, c’est à dire les utilisateurs de son application, qui ne passent pas par un MaaS.
Chacun de ces “mondes” étant en silo, il n’y a pas de problème de cohérence. L’inconvénient principal est qu’un utilisateur n’a pas une expérience sans couture en étant basculé vers l’application du MSP, puisque ses comptes sont décorrélés.
LES MYTHES DU COMPTE UNIQUE MAAS
Comment utiliser les standards d’identification et d’autorisation pour répondre aux attentes du MaaS
Edouard Bavoux
Le MaaS (Mobility-As-A-Service) est un ensemble de promesses, parfois des mythes, qui méritent d’être décryptées :
- Une application unique pour accéder aux services de mobilité d’un ensemble de MSP (Mobility-Service-Provider : Imaginez les VTC Uber, les trottinettes Lime, la RATP, Vélib ou encore Blablacar).
- Un Compte Utilisateur unique pour ces services, un moyen de paiement unique, l’achat d’offres intermodales…
Aujourd’hui : Focus sur le “Compte Unique de Mobilité”.
Les acteurs du MaaS parlent de “Compte de mobilité”, parfois comme synonyme au concept du MaaS, ou bien associé à de nombreuses informations : Les préférences de l’utilisateur en matière de mobilité, ses historiques de trajets quel que soit l’opérateur de mobilité utilisé, ses réservations ou produits mobilité.
Mais je parle ici du compte utilisateur, dans sa vision la plus réduite : un moyen d’échanger entre deux systèmes, à propos d’un même utilisateur. Cette notion de compte utilisateur est clé. Une plateforme MaaS et un MSP doivent pouvoir échanger à propos d’un même utilisateur. Tout le reste en découle : S’ils peuvent échanger à propos d’un même utilisateur, ils peuvent se tenir informés de ses achats, de ses préférences mises à jour, de ses trajets effectués, etc.
Le Partage du référentiel utilisateur…
… est la notion clé.
Un petit test sur la promesse du Compte unique:
En tant que voyageur, Bob: Vous débloquez une trottinette Lime avec une application MaaS. En fin de course, vous ouvrez l’application Lime pour terminer la course :
Vous vous attendez sûrement à voir votre trajet en cours, mais ce n’est pas le cas : Vous avez maintenant deux comptes Lime, et la course de trottinette est uniquement en cours pour votre compte Lime du MaaS. On se sent mieux n’est-ce pas ? On inspire à fond, on expire, tout va bien.
Un MSP donné peut participer à plusieurs MaaS. En conséquence : Bien que chaque plateforme MaaS ait l’ambition de proposer un “compte de mobilité unique”, il est impensable qu’un MSP utilise directement la base utilisateur d’un MaaS comme étant son propre référentiel.
Si l’on s’éloigne de ce constat logique, et de la tech, c’est évident qu’il faut définir les responsabilités de la gestion utilisateur : Le MaaS est il un vrai service auquel l’utilisateur souscrit, ou bien un simple intermédiaire ?
L’idée de cet article est de se pencher sur les solutions et problématiques techniques liées à ce choix. Volontairement, les autres aspects de la question, (juridiques, stratégiques,…), ne sont pas développés ici.
Il existe plusieurs alternatives, pour permettre à une plateforme MaaS et un MSP d’échanger à propos d’un même voyageur:
- Duplication des comptes MSP
- Partage de compte MSP
- Absence de compte MSP
Modèle 1 : Duplication des comptes MSP (ou compte technique)
Le MSP sépare ses référentiels utilisateurs pour chaque MaaS. Il sépare également son référentiel d’utilisateurs propre, c’est à dire les utilisateurs de son application, qui ne passent pas par un MaaS.
Chacun de ces “mondes” étant en silo, il n’y a pas de problème de cohérence. L’inconvénient principal est qu’un utilisateur n’a pas une expérience sans couture en étant basculé vers l’application du MSP, puisque ses comptes sont décorrélés.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Illustration : Duplication de compte utilisateur : Deux comptes pour Bob, dans le système du MSP
C’est pour ça, Bob, que tu as maintenant deux comptes Lime : Le compte Lime créé par toi avec l’application Lime, et le compte “technique” Lime créé pour toi par l’application MaaS, après ton consentement.
Ce modèle a l’immense avantage de fonctionner, d’être simple, et déjà mis en place par un ensemble de MSP, et quelques opérateurs MaaS.
Techniquement, c’est très simple : La plateforme MaaS et le MSP communiquent de serveur à serveur, de manière sécurisée : Clé d’API et HTTPS sont les minimums requis, et d’autres solutions additionnelles permettent de sécuriser davantage, comme la signature de message avec clé asymétrique. En général, c’est la plateforme MaaS qui pilote la création / suppression des comptes techniques de l’utilisateur dans le système du MSP, de manière plus ou moins transparente pour l’utilisateur. Puisque l’utilisateur n’a pas accès à ce compte technique MSP autrement qu’à travers cette plateforme MaaS, il n’y a pas d’information sensible d’authentification, de mot de passe personnel, rien qui nécessite une solution avancée.
Responsabilité et traitement des données personnelles : La plateforme MaaS est responsable des utilisateurs : Gestion des faux comptes, des doublons, validation des numéros de téléphones, des emails… La plateforme MaaS manipule les comptes techniques des différents MSP, ne fournit que les informations nécessaires aux services des MSP, et demande explicitement l’accord de l’utilisateur pour partager ses données.
Seul problème, ça ne répond pas tout à fait à la promesse d’un compte unique. Un utilisateur réel se retrouve avec plusieurs comptes pour un même service de mobilité, ce qui :
- Ne permet pas à l’utilisateur de basculer d’une application à l’autre (du MaaS au MSP).
- Empêche le MSP et la plateforme MaaS de réaliser une analyse d’usage poussée, et d’assurer l’unicité des utilisateurs du service, lorsque c’est nécessaire (par exemple pour éviter la fraude au covoiturage).
Modèle 2 : Partage de compte MSP (ou liaison de compte)
Le MSP garde un seul référentiel utilisateur, quelle que soit la plateforme utilisée pour accéder aux services de mobilité. Le MaaS n’étant pas une industrie mature, chaque opérateur MaaS peut souhaiter des processus spécifiques à sa plateforme. Un même utilisateur du système MSP peut être impacté par chacun de ces MaaS. Risque élevé d’incohérences.
Illustration : Partage du compte utilisateur MSP de Bob
Cette solution est plus complexe, ambitieuse, moins mature. Il y a principalement trois sources de difficultés pour la mettre en place (Autant pour les plateformes MaaS que pour les MSP) :
- L’intégration technique de la gestion des utilisateurs et de l’authentification du MSP.
L’axiome de base de ce modèle, c’est que le MSP est cette fois-ci responsable de ses utilisateurs. Cette partie ne peut plus être déléguée à chacun des MaaS qui souhaitent intégrer ce service. En effet, puisqu’il s’agit des mêmes utilisateurs, en déléguer la gestion à chacun des MaaS serait source de confusion, d’incohérence sur les process mis en place dans la gestion des utilisateurs, et la responsabilité d’offrir le service à l’utilisateur serait éclatée entre les différents intégrateurs, ce qui n’est pas souhaitable.
Ceci pose un ensemble de difficultés techniques pour sécuriser les processus de liaison de compte MSP à une plateforme MaaS, de gestion des tunnels d’inscriptions MSP, parfois complexes, et de gestion du mot de passe confidentiel de l’utilisateur pour ce service.
Deux solutions préconisées pour “lier” un compte MSP sont OAuth2 (Authorization Code Grant) ou OpenId Connect pour déléguer l’accès ou partager une authentification. Pour la création de compte MSP, l’utilisation de tunnels web (ou redirection web) est l’option la plus réaliste aujourd’hui, mais encore peu implémentée par les MSP.
- Le maintien de la cohérence de la solution.
Prenons l’exemple du paiement, pour une plateforme MaaS “modèle” qui intègre un service de paiement MaaS, et un système de réduction, ou de subventions.
Un petit test sur la cohérence du partage de compte MSP :
En tant que voyageur, Bob, vous réservez une voiture en autopartage à travers votre application MaaS. En cours d’utilisation, vous souhaitez prolonger la location, ou ajouter une option. Vous retrouvez votre location en cours sur l’application du MSP autopartage (Vive le partage de comptes MSP !) et vous modifiez.
Sauriez-vous dire si c’est le moyen de paiement enregistré dans votre application d’autopartage, ou dans l’application MaaS, qui sera utilisé ? Bénéficierez vous des tarifs avantageux de la plateforme MaaS ?
Autant de questions qu’il faut trancher et implémenter dans les systèmes du MSP et des différentes plateformes MaaS, pour maintenir une cohérence.
Cette deuxième difficulté, le maintien de la cohérence de la solution, n’est présente que lorsque le paiement, la valorisation (le fait de calculer le prix d’un service de mobilité) ou des règles métiers sont délégués aux plateformes MaaS.
- La liaison pourrait se faire dans les deux sens.
Pourquoi ne pas lier le compte MaaS dans l’application du MSP, en plus de l’autre sens ? Cela permettrait d’accéder aux services MaaS (aux tarifs, aux produits intermodaux) depuis la plateforme du MSP. C’est l’orientation que proposent les acteurs qui souhaitent favoriser l’usage de leurs applications mobiles, tout en faisant bénéficier l’utilisateur des avantages offerts par les produits MaaS.
En plus de ces 3 difficultés, cette solution ajoute des frictions dans l’expérience utilisateur du MaaS, et fait passer le service unique du MaaS derrière la notion de services fournis par des MSP.
Modèle 3 : Absence de compte MSP
Le MSP n’a pas de référentiel utilisateur. Il considère la plateforme MaaS comme étant son client, et n’a pas de système de gestion fine des utilisateurs finaux. C’est l’exemple classique d’une centrale de Taxi. De son point de vue, la plateforme MaaS a fait 178 courses ce mois-ci. Seule la plateforme MaaS consolide le lien entre des courses et des utilisateurs.
Illustration : Pas de compte utilisateur pour Bob dans le système du MSP.
Conclusion
La solution de partage de compte MSP entre les plateformes (modèle 2) n’est mature, aujourd’hui, que dans des contextes de plateforme MaaS “light”, sans délégation du paiement et sans logique propre au MaaS. C’est alors la solution privilégiée.
Pour une plateforme MaaS complète avec une intégration profonde, un paiement unifié, et des logiques métier propres : Il est nécessaire de pouvoir traiter les cas des modèles 1 (duplication de comptes MSP) et 3 (absence de comptes MSP). En revanche, on peut se poser la question de la pertinence du modèle 2 (partage de comptes MSP), indépendamment de son manque de maturité. Ce modèle ajoute une friction dans l’expérience du MaaS au moment des créations et liaisons de comptes, et il ne répond pas à l’un des objectifs du MaaS :
Offrir un réel service pour l’utilisateur final, qui peut alors faire passer les marques commerciales des MSP au second plan, après la contextualisation de l’offre :
Les solutions les plus proches, les plus rapides, les plus écologiques, les moins chères, dans son cas précis.
Ainsi, la gestion du modèle 2 dans le contexte d’une plateforme MaaS complète ne semble pas nécessaire, dans le contexte actuel.
Artigos recentes
Inovações em mobilidade
4 de abril de 2024
Comunidade e imprensa
