# Creating a Statement List

Statements are hosted in a JSON-encoded statement list in a well-known
location on a principal, as defined by the [Asset
Links Specification](https://github.com/google/digitalassetlinks/blob/master/well-known/details.md). A statement list contains one or more statements, and
a principal can have only one statement list.

## Statement list syntax

See the [statement list syntax](https://developers.google.com/digital-asset-links/v1/statements).

## Statement list location

The statement list is hosted in a well known location that depends on the type of *principal* (the website or app making the statements).

### Website statement lists

On a website, a statement list is a text file located at the following address:

<var translate="no">scheme</var>://<var translate="no">domain</var>/.well-known/assetlinks.json

Note the dot in the .well-known folder name.

Any response from the server besides `HTTP 200` is treated as an error, and will result in
an empty statement list. For HTTPS, any connection without a certificate chain that
can be verified with the trusted root list will also result in an empty statement list.

> [!NOTE]
> The assetlinks.json file must be served as `Content-Type: application/json` in the HTTP headers, and it cannot be a redirect (that is, `301` or `302` response codes are not followed).

**Example**

Here is an example statement list on a website: <http://example.digitalassetlinks.org/.well-known/assetlinks.json>

### Android app statement lists

In an Android app, the statement list is a JSON snippet with the same syntax as a website statement file, but it is embedded in the strings.xml file, and referenced in the manifest as shown next.

#### **In AndroidManifest.xml:**

```
<manifest>
  <application>
    ...
    <meta-data android:name="asset_statements" android:resource="@string/asset_statements" />
    ...
  </application>
</manifest>
```

#### **In res/values/strings.xml:**

```
<resources>
  ...
  <string name="asset_statements">
    ... https://developers.google.com/digital-asset-links/v1/statements ...
  </string>
</resources>
```

**Example**

Here is an example res/values/strings.xml snippet for an Android app that supports location sharing with the app (an Android feature not currently supported):

```
<resources>
    ...
    <string name="asset_statements">
      [{
        \"relation\": [\"delegate_permission/common.share_location\"],
        \"target\": {
          \"namespace\": \"web\",
          \"site\": \"https://example.com\"
        }
      }]
    </string>
</resources>
```

## Matching a target

Every statement is about a *target*. When you consume a statement, you must match the target in a statement against some entity in reality. If the statement target matches the entity, the statement applies. Here are the rules for determining if a target matches a given entity:

### **Website targets**

For a website, the site scheme, host, and port must match exactly. Default ports for HTTP and HTTPS (80 and 443 respectively) are assumed implicitly; if a statement target describes http://www.example.com:80, then the website http://www.example.com is considered a match.

**Example**

Given the following statement target

```
"target": {
  "namespace": "web",
  "site": "https://www.google.com"
}
```

The following URIs **WILL**match:

- https://www.google.com/
- https://www.google.com:443/
- https://www.google.com/foo
- https://www.google.com/foo?bar
- https://www.google.com/foo#bar
- https://user@password:www.google.com/

The following URLs **will NOT** match:

- http://www.google.com/ (*Wrong scheme*)
- https://google.com/ (*Host name does not match*)
- https://www.google.com:444/ (*Port does not match*)

### App targets

For an app, the certificate hash and package name of the target must exactly match the application.