UMA AS requesting VC: overview

[elf-pavlik]

Last week we discussed what role UMA AS would play. I think one of its main responsibilities would relate to gathering claims and setting appropriate ACRs/ACLs on the RS. Let's consider this flow roughly based on Use Case: 2.10.2. Possession of a verifiable credential

Let's call HCP-T the health care professional trying to access https://oscar.example/emergency. This resource requires medgov:HealthCareProfessional VC presented to access it.

Since we focus on UMA AS, I will intentionally omit a very important party of this flow. HCP-T should be able to control disclosure of his VCs to clients their use as well as approve app presenting his VC to some UMA AS. We should focus on this part of the flow separately, I'll just make it as User approves disclosing VC to the client and allows it to be presented to specific AS.

I will also not try to answer how exactly AS verifies the VC, which issuers are allowed to issue them etc.

1. HCP-T uses their client to make an unauthenticated request to https://oscar.example/emergency
2. RS responds with 401 and WWW-Authenticate including as_uri and ticket

• To indicate resources we could either use Resource Indicators for OAuth 2.0 or RS could have a way to provide that information when requesting ticket from AS

3. The client requests token from UMA AS advertised by RS using as_uri previous step
4. UMA AS responds with an error

HTTP/1.1 403 Forbidden
Content-Type: application/json

{  
   "error":"need_info",
   "ticket":"ZXJyb3JfZGV0YWlscw==",
   "required_claims":[  
      {  
         "claim_token_format":[  
            "https://www.w3.org/TR/vc-data-model/#json-web-token"
         ],
         "claim_type":"medgov:HealthCareProffesional"
      }
   ]
}

5. User approves disclosing VC to the client and allows it to be presented to specific AS
6. The client requests token from UMA AS, this time pushing VC as a claim
7. UMA AS verifies VC and provides Access Token
8. The client requests https://oscar.example/emergency, this time using the access token.

[acoburn]

It would be good to agree on the claim_token_format value(s), especially since there are different ways to express a VC. Expressing the VC as a JWT is one way to do this, but VCs can also be expressed as JSON-LD, and in that case I would suggest using this value https://www.w3.org/TR/vc-data-model/#json-ld.

I don't think this is an either/or proposition -- a server could support both JSON-LD and JWT-formatted VCs or it could support just one of those types. Either way, it would be important for the UMA server to advertise support in the .well-known/uma2-configuration resource in the uma_profiles_supported array.

[elf-pavlik]

I agree. I went with JWT here mostly assuming that UMA AS can already handle them and deal with signatures. Validating JSON-LD VCs may require adding bit more VC-specific features to AS.

[elf-pavlik]

FYI there is ongoing work on VC Insurance for OIDC (also linked from #329). It includes a section about clients requesting VCs which uses authorization_details

[
   {
      "type":"openid_credential",
      "format":"jwt_vc_json",
      "types":[
        "VerifiableCredential",
        "UniversityDegreeCredential"
      ]
   }
]

I think aligning it with what UMA server response includes in required_claims, could provide a straightforward way for clients to obtain the credentials they need to push as a claim.