[Openid-specs-mobile-profile] level of assurance as acr_values in mobile profile

Wed Feb 11 14:12:23 UTC 2015

Hi Joerg,

Some personal feedback, without answering to the question, but hope this helps:

1- in OIDC core specs we have:
5.5.1.1.  Requesting the "acr" Claim
If the acr Claim is requested as an Essential Claim for the ID Token with a values parameter requesting specific Authentication Context Class Reference values and the implementation supports the claims parameter, the Authorization Server MUST return an acr Claim Value that matches one of the requested values. The Authorization Server MAY ask the End-User to re-authenticate with additional factors to meet this requirement. If this is an Essential Claim and the requirement cannot be met, then the Authorization Server MUST treat that outcome as a failed authentication attempt.

This seems to consider the acr parameter as only referencing the authentication function:
-       with a values parameter requesting specific Authentication Context Class Reference values
-       The Authorization Server MAY ask the End-User to re-authenticate with additional factors to meet this requirement.

16.20.  Need for Signed Requests
In some situations, Clients might need to use signed requests to ensure that the desired request parameters are delivered to the OP without having been tampered with. For instance, the max_age and acr_values provide more assurance about the nature of the authentication performed when delivered in signed requests.

This seems to consider the acr parameter as only referencing the authentication function:
-       max_age and acr_values provide more assurance about the nature of the authentication performed

2.  ID Token
        acr
           Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value "0" indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 (International Organization for Standardization, "ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework," March 2013.) [ISO29115] level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of "level 0" is appropriate. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value.

This seems to consider the acr parameter as only referencing the authentication function:
-       Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied

2- In ITU-T Recommendation X.1254 doc we have:
https://www.oasis-open.org/committees/download.php/44751/285-17Attach1.pdf

Assurance within this Recommendation | International Standard refers to the confidence placed in all of the processes, management activities, and technologies used to establish and manage the identity of an entity for use in authentication transactions.

Question: are we allowed to consider that OpenID Connect specifications, through the acr parameter, consider solely the Entity authentication phase (3rd part of the above sheet), or not ?

Kind regards,
Philippe

[X]

-----Message d'origine-----
De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de Connotte, Joerg
Envoyé : dimanche 8 février 2015 20:52
À : openid-specs-mobile-profile at lists.openid.net
Objet : [Openid-specs-mobile-profile] level of assurance as acr_values in mobile profile

Dear all,

I wanted to share some considerations we discussed about how to address the task of specify standard values for acr in the Mobile Profile.

Making a distinction between identity and credential of an entity:
The levels of assurance as defined in ISO29115 mix up the assurance about the identity of an entity and assurance about the credentials of an entity used during authentication.
However those two aspects of an entity are altogether different and basically independent of each other.

Identity of an entity is information about certain (personal) data of an entity. In case the entity in question is a real person examples for those are: given name, last name, birthday, address etc.
Thus assurance about identity concern itself with answers to the questions how well the information about this identity is validated. I other words how much effort was taken to ensure the correctness of the data. During authentication this information is not re-validated.

Credentials:
Credentials are secrets in possesion of and in some cases controlled by an entity which are used to validate an authentication.
Typical credentials are username/password, mobile network, fingerprint etc.
Assurance about credentials concerns itself with the trustworthiness of the mechanisms actually used to protect those credentials.

Implications:
Assurance that an entity is the same over consecutive authentication processes can rely solely on the assurance of the protection of the credentials of this entity. It is not necessary to know anything about the identity of the entity.

It is theoretically possible to have a high level of assurance about the correctness of certain identity information about an entity without a high level of assurance about the correctness of the credentials of the same entity.
Moreover validating identity information about an entity may be difficult whereas providing a trustworthy set of credentials is relatively easy.

Proposition for Mobile Profile:
The definition of a separate set of acr values for 'credential assurance' and 'identity assurance' seems to be a useful thing to consider. For most use cases discussed in the Mobile Connect project secure authentication without exposing any identity data execpt a unique identifier is sufficient.

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>
www.telekom.com<http://www.telekom.com>

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.

_______________________________________________
Openid-specs-mobile-profile mailing list Openid-specs-mobile-profile at lists.openid.net<mailto:Openid-specs-mobile-profile at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

_________________________________________________________________________________________________________________________

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/20150211/8c914832/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture (Device Independent Bitmap) 1.jpg
Type: image/jpeg
Size: 71201 bytes
Desc: Picture (Device Independent Bitmap) 1.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150211/8c914832/attachment-0001.jpg>