[Openid-specs-mobile-profile] AMR values for authentication spec

John Bradley ve7jtb at ve7jtb.com
Thu Dec 10 14:49:52 UTC 2015

It is not required that they understand them.  They are additional information beyond the amr. 

I suspect they are only really useful to people running some sort of adaptive risk engine.  

If a bank knows that the device the user authenticated on is using a class 0 SMS push of a URL to a device with click to confirm,  they might treat that differently to a authentication using a class 2 sms directly to the SIM that is confirmed with a signed challenge based on a user clicking a prompt.

I suspect that you need a relatively sophisticated person to understand the risks of the first vs the second and add additional mitigations for the possibility of message interception in the first case.
(No criticism of people deploying the first case intended)    It may be that a given handset is capable of the first but not the second however they are both the same http://schemas.openid.net/policies/mod/phishing-resistant <http://schemas.openid.net/policies/mod/phishing-resistant> acr value.

Giving the client the ability to differentiate in the request is not useful because the SIM in the users device can’t be updated magically during the authentication.
However a sophisticated client/SP may want to know and give that info to a risk engine.   

Now I grant you that intercepting the SMS and triggering it is not the work of a casual remote attacker, but I know people who have that ability if they wanted to target an individual, they would sit outside the persons house with a stingray and trigger a authentication to grab the confirmation URI and authorize themselves to get into an account.  All with a legal court order no doubt:)

That is not a distinction that I would worry most clients/RP with, but some will care, and so they can look at the amr values.

I will fix the duplicated lines, that was just a cut and paste error.

Are there other examples that people want me to add, or comments on the existing ones?

Trying to group these in a sensible way is something I am mostly making up, so feel free to comment.

In some ways it may be best to have the ACR and AMR details in a separate document and just have the protocol information.
On the other hand this is likely the only doc developers will look at so I duplicated some of the amr text from the RFC draft.

John B.

> On Dec 10, 2015, at 11:07 AM, <philippe.clement at orange.com> <philippe.clement at orange.com> wrote:
> Hi John,
> Thanks for the updates
> Just a minor remark: an overlap between lines 291-294 and lines 296-299
> Is it useful to insert a text mentionning the necessary understanding (by the RP) of amr values returned by the OP, or do we consider them as “fire and forget” elements  ?
> Regards,
> Philippe
> De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de John Bradley
> Envoyé : jeudi 10 décembre 2015 01:50
> À : Openid-specs-mobile-profile
> Objet : [Openid-specs-mobile-profile] AMR values for authentication spec
> I have added a new section explaining AMR and showing some of the values from the registry.
> https://bitbucket.org/openid/mobile/diff/draft-mobile-authentication-01.txt?diff2=2d1046613672&at=default <https://bitbucket.org/openid/mobile/diff/draft-mobile-authentication-01.txt?diff2=2d1046613672&at=default>
> I am working with Mike Jones to align with the registry values.
> https://tools.ietf.org/html/draft-jones-oauth-amr-values-02 <https://tools.ietf.org/html/draft-jones-oauth-amr-values-02>
> John B.
> _________________________________________________________________________________________________________________________
> 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/20151210/c0a17a36/attachment-0001.html>

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