Versions Compared

Old Version 7

changes.mady.by.user Former user

Saved on

compared with

New Version 8

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. The host looks up the authorization manager metadata and learns about API endpoints and formats supported by the AM
  2. The host obtains OAuth client credentials and a the location of the resource registration API from the authorization manager.
  3. The host obtains an access token from the authorization manager by following the OAuth 2.0 web server flow.
  4. The host registers the authorization user's resources with the AM by using the resource registration API.
Note
titleTODOs/Issues
  • Host and AM can both decide if they work with the other side
  • AM can refuse client id/secret. Needs error conditions
  • How can the Host trust the AM? There are trust frameworks around for that these days
  • no big difference between RRAPI to be in hostmeta or provisioned in step 2. Needs more input to get decision
  • step 2 might be a separate specification.
  • maybe in this specification the server can put in additional data specific to some namespace. Example:
    Code Block
    
    { 'client_id' : '72z81uhbjhssd867e',
      'client_secret' : 'test123',
      'expires_in' : 3600,
      'http://uma/am/resource_registration_uri' : 'http://....',

host looks up the authorization manager metadata

...