[Openid-specs-mobile-profile] Issue #1: Context

philippe.clement at orange.com philippe.clement at orange.com
Thu Jul 2 15:09:41 UTC 2015

Hi Joerg,

I agree on the differences between the 2 use cases, and the description you made.

On Use Case 2, I'm wondering on the meaning of "Here the purpose of the context is to make sure that the user is aware that he has to authorize a certain transaction which does not necessary include a primary authentication".
Does it mean that no authentication at all may have occurred before the transaction confirmation request, or at least some other types of authentication ?

On another hand, do you consider that the use case 2 enters into the "consent" perimeter ?


De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de Connotte, Joerg
Envoyé : mercredi 1 juillet 2015 09:52
À : openid-specs-mobile-profile at lists.openid.net
Objet : [Openid-specs-mobile-profile] Issue #1: Context

Hi all,

in our last call we had a lengthy discussion about Issue #1.

In my opinion we are talking about two different use cases where context is useful. But the requirements about the context are very different for those use cases

1)      Context for authentication/login. Here the purpose of the context is to create an interlock between the consumption device and the authentication device to allow the user to make sure that the request to log in really comes from a process he himself initiated on the consumption device. To facilitate this some nonsense text would be sufficient. In any case there is no need to have a structured context or some mechanisms to process the context besides show the context-text on the authentication device AND the consumption device.

2)      Context to authorize business transactions (e.g. payment transactions). Here the purpose of the context is to make sure that the user is aware that he has to authorize a certain transaction which does not necessary include a primary authentication. This implies that the context is highly structured and is processed in the IdP. For example for a payment transaction the IdP has to understand that this is a payment transaction and has to store context (and possibly the whole transaction) to allow for non-repudiation issues.

What do you think?

Kind Regards
Jörg Connotte

Deutsche Telekom AG
Products & Innovation
Jörg Connotte
Customer Platforms
T-Online-Allee 1, 64295 Darmstadt
+49 6151 680-7288 (Tel.)
+49 151 184-15517 (Mobil)
E-Mail: j.connotte at telekom.de<mailto:j.connotte at telekom.de>

Life is for sharing.

You can find the obligatory information on www.telekom.com/compulsory-statement<http://www.telekom.com/compulsory-statement>

Big changes start small - conserve resources by not printing every e-mail.


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150702/5d8f7cd1/attachment.html>

More information about the Openid-specs-mobile-profile mailing list