I have a scenario in which a service provider is offering an API for incoming messages. It is not possible for this service to require pre-registration of clients because of the number of possible clients, or the type of clients. In this scenario, the server is most likely a small site, while the clients are large providers. It is not likely that these large providers will bother to register with the server. In addition, the server might want to maintain a white or black list of allowed clients.
The way this works is: 1. Client makes a signed request to deliver a message to a user on the server. The request is signed using the client's private key, and includes the account of the sender which is under the control of the client (i.e. acct:j...@example.com). 2. The server receives the message and obtains the host-meta document for example.com using SSL/TLS. The host-meta document either includes the corresponding public key for the client (for this purpose) or links to one. 3. The server verifies the request by checking the signature using the public key. This can be modified to include delegation, in which the client uses a private-key signed request to obtain a token with the usual flows involving a user. The purpose of this flow is to avoid client registration while still verifying the client's identity and potentially agreement to terms of service (assuming they can be represented in a machine readable way in the client's host-meta document). This flow uses SSL/TLS for obtaining the host-meta document (which will likely include more steps to verify trust), as well as likely to use SSL/TLS for making API calls to maintain message privacy in transit. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
