Trusted Facet List

507 views
Skip to first unread message

Aaron Adelman

unread,
Jul 12, 2016, 5:42:10 AM7/12/16
to FIDO Dev (fido-dev)
Hello, everybody.

In working on my iOS FIDO client/ASM/FIDO authenticator, I realized I somehow overlooked half an item in the registration process (UAF protocol specification §3.4.6.2, item 5, part 2):  "Verify that the FacetID is authorized for the AppID according to the algorithms in [FIDOAppIDAndFacets]."  I thus got to work implementing the missing half-item, detailed in FIDO AppID and Facet Specification v1.0 §3.1.2 Determining if a Caller's FacetID is Authorized for an AppID.  And then I ran into trouble in item 4:  "Begin to fetch the Trusted Facet List using the HTTP GET method. The location must be identified with an HTTPS URL."

The problem is that it doesn't seem to be specified where the Trusted Facet List is located.

I discussed the problem with a coworker, and we think what's being requested is metadata, in which case I can deal with the situation by getting our FIDO client/ASM/FIDO authenticator registered with the metadata service.  I presume the metadata service will provide a URL that my app can use to download the Trusted Facet List from.

My coworker also mentioned seeing a FIDO Webinar in which it was claimed that many companies are deliberately opting out of registering their metadata.  I presume if we go that route, my code should assume the FacetID is authorized for the AppID.

Do I understand the situation correctly?

Thanks in advance.

Aaron Adelman

Arshad Noor

unread,
Jul 12, 2016, 1:25:18 PM7/12/16
to fido...@fidoalliance.org
Depends on how you define "metadata", Aaron.  Pulling down the Trusted Facets is retrieving "metadata" about which origins can be trusted for interacting with the Authenticator, but in the context of UAF, it is not a "metadata statement" as defined by the UAF Metadata Service.

Your Trusted Facet List can be stored anywhere you want - as long as it identifies the content necessary for the FIDO Client to process it correctly (our demo file is located here) and it can be retrieved using these rules:

"The URL MUST be dereferenced with an anonymous fetch. That is, the HTTP GET MUST include no cookies, authentication, Origin or Referer headers, and present no TLS certificates or other forms of credentials."

Can you post a link to the webinar that claims companies are opting out of registering their metadata statements?  I am curious to understand why.  If your company goes that route, I would also be interested in understanding the motivation behind that decision if you're willing to share it (publicly or privately). 

Thank you.

Arshad Noor
StrongAuth, Inc.

Ki-Eun Shin

unread,
Jul 12, 2016, 9:27:45 PM7/12/16
to FIDO Dev (fido-dev)
In UAF, metadata is the information describing the authenticator. Also, the metadata service (MDS) is a kind of repository for maintaining the metadata and it provides the way to get metadata and its status to FIDO servers.

Metadata is not related to the trust facet list.

In order to define the location of getting trusted facet list, you need to understand the scope of the credential (pub/priv) key pair registered to the FIDO server.

In UAF, the registered user key is uniquely identifier with (AAID, AppID, UserName) combination, which means that the key is valid only for the AppID.

You can define AppID as for native application or web application. For native application, you can assign AppID for the Application (apk hash for android, bundle-id for ios).

But normally, RP offers the number of applications which are essentially same or share the identity between applications.

In this case the RP needs to define the AppID to cover these applications to share the same credential which means that after registering on one service, there is no need to re-register on other services.

For this reason, RP can assign the location of getting trusted facet list with web URL (which is AppID) and provide trusted facets to FIDO clients.

Any URL running under RP can be AppID.

But the AppID is the type of web URL, by default, Same origin policy is applied to the credential scope.

And the facet having web URL should follows some conditions to avoid accessing credential with malicious apps.

Here's the example.

AppId (location to get trusted facet list): https://www.syrup.co.kr/appID
Trusted Facet List
1. certificate hash of apk (Android app 1)
2. certificate hash of apk (Android app 2)
3. bundle-id (IOS app 1)

Thanks.

Aaron Adelman

unread,
Jul 13, 2016, 3:10:11 AM7/13/16
to FIDO Dev (fido-dev)
You can find the Webinar at https://www.youtube.com/watch?v=X_aD1NNZOGc .

Aaron

Adam Powers

unread,
Jul 13, 2016, 10:27:15 AM7/13/16
to Aaron Adelman, FIDO Dev (fido-dev)
I was the one that made that statement in the webinar, so let me clarify here: I would certainly encourage companies to register their metadata in MDS. The companies that aren’t registering their metadata in MDS are mostly “very large mobile OEMs / HSVs” that are dealing directly with relying parties.

Unless your company has the reach to interface directly to a large number of relying parties, the best way of making sure that your authenticator is going to work with different relying parties is through MDS.

I hope that helps.

Thanks,
Adam
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/723e375c-ff98-46ac-a7b9-3a328f7c5a27%40fidoalliance.org.

Arshad Noor

unread,
Jul 13, 2016, 3:04:48 PM7/13/16
to fido...@fidoalliance.org
I'm not sure I understand this, Adam.

If an Authenticator manufacturer did not register with a publicly visible MDS, they are effectively restricting their Authenticator to be useful only with servers that know where to get the metadata statement for their product.  That is counter-intuitive.  I would imagine that if I were manufacturing an Authenticator, I would want any FIDO Server to be able to download the metadata-statement from a publicly visible MDS so any RP in the world that used any FIDO Server should be able to use my Authenticator to register a user's key.  To deliberately keep ones metadata statements out of a publicly visible MDS makes the Authenticator appear to be "untrusted" and potentially "insecure"

Can you elaborate how a third-party FIDO Server can work with Authenticators whose metadata statements are not available from FIDO Alliance's MDS?  Forcing a FIDO Server manufacturer to negotiate with each Authenticator manufacturer appears counter-productive to the ecosystem and to the sales strategies of the Authenticator manufacturers.  If an RP chose to do this deliberately, that's one thing; but to make one's Authenticator "invisible" to any RP/FIDO Server that was willing to work with the Authenticator through a publicly visible MDS, appears contradictory.

Thanks.

Arshad

Adam Powers

unread,
Jul 13, 2016, 7:03:04 PM7/13/16
to Arshad Noor, fido...@fidoalliance.org
I think we are in violent agreement.
--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

Phuong Nhu

unread,
Jul 20, 2016, 10:46:19 PM7/20/16
to FIDO Dev (fido-dev)
Can i use your URL for my server to test with that TrustedFacet? I can not join in this URL, so how to build this for allow " conditions to avoid accessing credential with malicious apps"? Thank you very much!

Vào 08:27:45 UTC+7 Thứ Tư, ngày 13 tháng 7 năm 2016, Ki-Eun Shin đã viết:

Ackermann Yuriy

unread,
Jul 21, 2016, 11:11:56 PM7/21/16
to FIDO Dev (fido-dev)

Could some one explain how does google serves their facets from gstatic.com and not google.com?

https://www.gstatic.com/securitykey/a/google.com/origins.json

21 июля 2016 г. 2:46 PM пользователь "Phuong Nhu" <nhuphuo...@gmail.com> написал:

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

Alexei Czeskis

unread,
Jul 22, 2016, 1:51:48 AM7/22/16
to Ackermann Yuriy, FIDO Dev (fido-dev)
It's a pre FIDO specifications artifact.


Thanks!
-Alexei

________________

 . Alexei Czeskis .:. Securineer .:. 317.698.4740 .


Reply all
Reply to author
Forward
0 new messages