Registration of Attribute Server to the Authorization Server

As part of the PEAFIAMP project, we are now working on the Attribute Server – Authorization Server introduction. Here, “introduction” is done in the following steps:

1. SP requests certain attributes to the authorization server, using the standardized (registered) vocabulary.
2. Authorization server, since it does not yet know where the attributes lives, it asks the user where it is using incremental search like user interface.
3. The user selects the attribute server.
4. The authorization server GETs the meta-data from .well-known (see exhibit A). It is expressed in JSON. The JSON should express the entity name, service type, public keys, supported attributes. (Note: since this metadata is publicly available, a search engine company may harvest them and provide nice user interface for the use in step 2.)
5. The authorization server dynamically registers itself to the attribute server using dyn-reg. During the dynamic registration, the attribute server shall check if the authorization server is a trusted third party (TTP) certified authorization server in the trust framework. During the process, the attribute server obtains the authoritative public key of the authorization server.  (Note: is there other ways of establishing trust?)
6. Account Linking: “For the user” implies that there is some way of linking a user at the attribute server to the user at the authorization server. In some countries like Denmark/Sweden etc., it is simpler to do so, as data is likely authoritatively associated with the respective social numbering system. In other countries like Japan, it is harder. We may consider using “Basic 4 information (Registered name, registered address, date of birth, and gender)”, or do active authentication at the attribute server as well to link the accounts. (This may be done realtime if the attribute server provides accounts. Otherwise, it would have to send out a one time code to the user, which is a major usability hassle. It would be highly dependent on the existing system).
7. Registering the authorization server as authoritative for the user: Now that accounts are linked and the authoritative authorization server key is obtained, the attribute server records the authorization server as authoritative for the user authorization for this particular user. Since it now has the authoritative public key, it can verify the JWT based access token issued by the authorization server for the user.

The following is the conceptual example of the attribute server meta-data that is obtained from .well-known/attribute-server-meta

{
  "_links":{
    "resource_endpoint":{
       "href":"https://server.example.gov/userdata/{user_id}",
       "Authorize":"Bearer {access_token}",
       "templated":true
    }, 
    "registration_endpoint":{
       "href":"https://server.example.gov/register"
    }
  }
  "entity_name":"National Health Center", 
  "entity_id" : "https://nhc.example.gov", 
  "supported_attributes":[
    "medical_checkup_records",
    "blood_type",
    "name",
    "birthdate",
    "gender",
    "user_id",
    "updated_time"]
}

The following is the sequence diagram of the registration flow.

title Attribute GET Sequence

Alice->SP: "Want your service"
SP->Alice: "Select your AuthZ server"
SP-->Alice: "Get Attributes"
Alice->AuthZ: "Need these attributes"
AuthZ-->Alice: "Where is the attributes?"
Alice->AuthZ: "some string"
AuthZ-->Alice: "candidates"
Alice->AuthZ: "This is the one"
AuthZ->AttrS: "GET .well-known/attr-meta
AttrS-->AuthZ: JSON metadata
AuthZ->AttrS: Register me as AuthZ of Alice
AttrS->AttrS: Account Linking
AttrS->TTP: Is this AuthZ OK? 
TTP-->AttrS: Here is the key hash
AttrS-->AuthZ: Registration Complete
AuthZ-->SP: Endpoint+Access Token
SP->AttrS: GET data w/ access_token
AttrS-->SP: data

And for the aggregated claim case:

title Attribute GET Sequence
participant Alice
participant SP
participant AuthZ
participant Proxy
participant AttrS
participant TTP

Alice->SP: "Want your service"
SP->Alice: "Select your AuthZ server"
SP-->Alice: "Get Attributes"
Alice->AuthZ: "Need these attributes"
AuthZ-->Alice: "Where is the attributes?"
Alice->AuthZ: "some string"
AuthZ-->Alice: "candidates"
Alice->AuthZ: "This is the one"
AuthZ->AttrS: "GET .well-known/attr-meta
AttrS-->AuthZ: JSON metadata
AuthZ->AttrS: Register me as AuthZ of Alice
AttrS->AttrS: Account Linking
AttrS->TTP: Is this AuthZ OK? 
TTP-->AttrS: Here is the key hash
AttrS-->AuthZ: Registration Complete
AuthZ-->SP: Endpoint+Access Token
SP->Proxy: GET data w/ access_token
Proxy->AttrS: GET data w/ access_token
AttrS-->Proxy: data
Proxy-->SP: data

We need to define the vocabulary for the attributes. Also, the standardized access token format would be required (or we need token resolution endpoint defined.)