Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep HOWTO-chrome.md up to date #506

Merged
merged 8 commits into from
Oct 18, 2023
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 54 additions & 5 deletions explorations/HOWTO-chrome.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ includes the time when the sign-up status was set.

## Experimental functionality

In order to test experimental functionality:
To test experimental functionality:

1. Download Google Chrome Canary. It is best to experiment with the latest
build possible to get the most up-to-date implementation.
Expand Down Expand Up @@ -67,7 +67,7 @@ succeeded or failed.

### LoginHint

In order to use the LoginHint API:
To use the LoginHint API:

* Enable the experimental feature `FedCmLoginHint` in `chrome://flags`.
yi-gu marked this conversation as resolved.
Show resolved Hide resolved
* Add an array of `hints` to the accounts described in the accounts endpoint:
Expand Down Expand Up @@ -102,7 +102,7 @@ Now, only accounts with the "hint" provided will show in the chooser.

### UserInfo

In order to use the UserInfo API:
To use the UserInfo API:

* Enable the experimental feature `FedCmLoginHint` in `chrome://flags`.
yi-gu marked this conversation as resolved.
Show resolved Hide resolved
* The RP must embed an IDP iframe, which will perform the query.
Expand All @@ -128,7 +128,7 @@ user_info.forEach( info => {

### RP Context

In order to use the RP Context API:
To use the RP Context API:

* Enable the experimental feature `FedCmRpContext` in `chrome://flags`.
yi-gu marked this conversation as resolved.
Show resolved Hide resolved
* Provide the `context` value in JS, like so:
Expand All @@ -149,7 +149,7 @@ Now, the browser UI will be different based on the value provided.

### IdP Sign-in Status API

In order to use the IdP Sign-in Status API:
To use the IdP Sign-in Status API:

1. Enable the experimental feature `FedCM with FedCM IDP sign-in status` in `chrome://flags`.
2. When the user logs-in to the IdP, use the following HTTP header `IdP-SignIn-Status: action=signin`.
Expand All @@ -158,3 +158,52 @@ In order to use the IdP Sign-in Status API:
5. The browser is going load the `signin_url` when the user is signed-out of the IdP.
6. Call `IdentityProvider.close()` when the user is done logging-in to the IdP.

### Error API

To use the Error API:

* Enable the experimental feature `FedCmError` in `chrome://flags`.
* Provide an `error` in the id assertion endpoint instead of a `token`:
```
{
"error" : {
"code" : "access_denied",
"url" : "https://idp.example/error?type=foo"
}
}
```
yi-gu marked this conversation as resolved.
Show resolved Hide resolved
Note that the `error` field in the response including both `code` and `url` is
optional. As long as the flag is enabled, Chrome will render an error UI when
the token request fails. The `error` field is used to customize the flow when an
error happens. Chrome will show a customized UI with proper error message if the
code is "invalid_request", "unauthorized_client", "access_denied", "server_error",
or "temporarily_unavailable". If a `url` field is provided, Chrome will add an
affordance for users to open a new page (e.g., via pop-up window) with that URL
to learn more about the error on that page.

### `AccountAutoSelectedFlag` API

To use the AccountAutoSelectedFlag API:
* Enable the experimental feature `FedCmAccountAutoSelectedFlag` in `chrome://flags`.

The browser will send a new boolean to represent whether auto re-authentication was triggered such that the account was auto selected by the browser in the flow to both the IdP and the API caller.

For IdP, the browser will include the boolean `is_account_auto_selected` in the request sent to the id assersion endpoint:
yi-gu marked this conversation as resolved.
Show resolved Hide resolved
```
POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true&is_account_auto_selected=true
```

For the API caller, the browser will include the boolean `isAccountAutoSelected` when resolving the promise with the token:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For the API caller, the browser will include the boolean `isAccountAutoSelected` when resolving the promise with the token:
For the Relying Party, the browser will include the boolean `isAccountAutoSelected` when resolving the promise with the token:

Thinking this might be more consistent language here, but not certain.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While it's true that API is called on the RP site, the API caller could be the RP itself or the IdP (via SDK) or 3P library that uses FedCM API.

```
{
yi-gu marked this conversation as resolved.
Show resolved Hide resolved
"token": "eyJC...J9.eyJzdWTE2...MjM5MDIyfQ.SflV_adQssw....5c",
"isAccountAutoSelected": true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

providing this information seems like it would be unnecessary. What's the motivation for indicating this to the RP/IDP rather than just making this a client side only piece of information? Say for example, that the user doesn't auto select an account could that reveal information about whether or not it's a temp account versus a primary permanent account based on statistical analysis?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you elaborate a bit on the attacking vector here? I'm not sure if I understand what you meant by temp account v.s. primary account. The boolean can only be true for "returning" account which means that the user has used that account in this browser client in the past.

For motivation and privacy & security considerations, please see #497

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I'll have to give a read into this a bit further. I wasn't aware of the linked issue before this, but just came across it. Do you guys have a glitch.me demo of this feature built by chance? I'd like to play around with this feature a bit more to make sure I'm understanding the goals and am able to assess the potential impact correctly.

FWIW, don't block this on my review but my hunch does think this is probably oversharing information. If I come up with a practical attack then it could always be reverted later too.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could try https://webid-fcm.glitch.me after enabling the flag. The boolean will be displayed in the log section.
Note: in Chrome, after auto re-authen is triggered, it will be suppressed for 10 mins (or until a user explicitly signs in).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Kyle, ok with us merging this howto change or do you have any further comment?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah fine to merge as is. I'll take a look into this post merge when I pick up some time to see if I spot any concerns with it. If I do find something I'll open an issue with follow up suggested changes.

}
```
Loading