Some websites have been built to demonstrate a model called Street Identity. The general idea is that there are 4 parties involved:
- The user
- A "relying party" website that needs to get a trustworthy street address for a user, for example to see if that business has some historical records associated with the user at that address
- An "attribute provider" that has verified the user's street address of the user, and is trusted by the RP to assert that address
- The user's main "identity provider" that they most frequently use to login to websites
The end-user experience is that the user logs into the relying party by clicking the button of their identity provider, an agrees to both be logged into that website AND to have their street address shared. However behind the scenes the relying party DOES NOT get the user's address from the identity provider. Instead the identity provider gives the relying party a token that it must then send to the attribute provider to get a trustworthy assertion of the user's street address. The separation of identity provider and attribute provider is the key goal that we want to show in the demos. It provides a lot of potentially powerful capabilities such as:
- Attribute providers charging relying parties for the information provided
- Improved usability on the relying party website by leveraging the user's relationship with their main identity provider
- Improved control for the user by leveraging the identity provider's experience with consent flows, and the attribute provider's experience with special information or APIs
There are multiple technologies that could be achieved to implement these demos (OAuth2, OpenID, JWT, UMA, AX, ...). We are mostly using OpenIDConnect for federated login, OAuth2 for read/write access to the street identity API, and a special call the RP can make to the IDP to request a JWT token that it sends to the AP to get a user's actual street address. For more details on the flow and high level summary of the APIs, see
the user flows doc. We plan to provide more API documentation in the future, and open source versions of the demo apps.
Here are instructions to try out the demo
Currently it is a stand alone demo site, so you need to register to create an account. You can use any email address you want, the demo site will not try to validate it.
We are working on an updated version that just works with a user's existing Google account.
Currently the demo AP requires you to login using the demo identity provider. However in a real world environment, the AP would probably be an existing website with its own login system such as a bank, telco, etc.
When you login, an OAuth flow is started with the identity provider to get the user's consent for the AP to Manage the users verified street addresses. Even if the AP had its own login system, it would still need to perform an OAuth flow to get this permission
After these steps are done, you will see a note that your account at the AP does not have any addresses. In a real world environment, the AP might actually already have an address for you. For example, if the AP was your bank or telco then it generally will already have your address. But for this demo, lets say the AP does not actually have the user's address, but is helping them get a verified address that they can then share in the future with a relying party website.
So go ahead and click "Add new address" and then submit the form after filling it out (you can use a fake address)
In this particular example, the AP is verifying the user's address by sending a postcard to their claimed street address. That postcard would tell them to come back to the AP's site and enter a unique code printed on the postcard. However for this demo we let you cheat. Just click the "See my postcards" link. Copy the long code that is shown, go back to the account page, paste in the code, and hit verify.
3) Confirm your IDP knows about your verified address
Go back to http://streetidentity-idp.appspot.com and you should see confirmation that the IDP knows the descriptive name of your newly verified street address. However it doesn't actually know the street address itself, just the descriptive name.
The demo says you will be logging in with your Google account, but currently it is still using the demo account you created at the demo IDP
The user will see a standard consent page asking them to confirm they want to log into this site, and let it read the user's street addresses
Once that consent is given, the user is logged in, and the RP is able to list the descriptive names of the verified addresses
Click "use this address" and the RP will get a token from the IDP that it sends to the AP, and finally gets your actual verified address
In the real world the RP could then use that to do things like find some historical records associated with the user at that address, and show it to them
Notice that steps 1-3 only need to be performed once by a user. In the future, they can visit any RP they want, and by simply clicking 2 buttons (1 for the IDP and 1 for consent), the RP can then display any information it has about the user at that street address.
Contact "Eric Sachs" <Esachs@google.com> to request access