W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2016

Re: [webauthn] Clarify meaning of UVI

From: gmandyam via GitHub <sysbot+gh@w3.org>
Date: Mon, 08 Aug 2016 15:07:45 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-238267199-1470668863-sysbot+gh@w3.org>

" I am not sure that this webauthn spec is the right place to mandate 
a specific implementation as this cannot be verified by the Web 
Browser, nor the calling app. But since this proposal uses a rawUVI 
value which could be computed in an implementation specific way, 
requiring this furmula doesn't effectively restrict implementations 
either (IMHO). "

The impetus (at least in part) for proposing a new def.'n of UVI was 
to demonstrate that UVI was not opaque data and inscrutable from the 
browser perspective.  Assuming UVI is derived from a strong hash of 
values into which the browser has no insight, the UVI is for all 
intents and purposes opaque.  This proposed definition does not change
 that.  So IMO a viable alternative is to define a specific method for
  generating rawUVI.  UVI opaqueness will still be an issue, but an 
authenticator would presumably not be able to stuff rawUVI with 
whatever it wants and survive scrutiny (e.g. by 3rd-party 
certification or perhaps legal means - see [1]).

"I'm still not sure how to ensure this does not become a way for the 
authenticator to pass 32 bytes of whatever it wants to the RP, since 
the client has no way to tell if the value returned by the 
authenticator is a UVI or say an encrypted GPS coordinate. In this 
regard UVM seems more tractable."

I agree that this is an issue with UVI, but we has a discussion on the
 list several months ago [1] and seemed to come to a consensus that an
 authenticator that is doing something it has claimed it would not do 
can result in potential action by the client vendor.  Nevertheless, as
 long as we do not define a specific method for generating rawUVI, the
 authenticator could potentially overload it and claim to be in 
compliance with the specification.


GitHub Notification of comment by gmandyam
Please view or discuss this issue at 
using your GitHub account
Received on Monday, 8 August 2016 15:10:00 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:22 UTC