1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect

Wiki

Clone wiki

connect / Connect_Meeting_Notes_2021-02-15_Pacific

View History

OpenID AB/Connect WG Meeting Notes (2021-02-15)

The meeting was called to order at 23:01 UTC.

1.   Roll Call

  • Attending:
    • Adam Lemmon
    • Anthony Nadalin
    • Bjorn Hjelm (Verizon)
    • David Waite (Ping Identity)
    • Edmund Jay
    • Kristina yasuda
    • Nat Sakimura
    • Tom Jones
    • Vittorio Bertocc
  • Regrets:
  • Guest:

3.   NIST Ontology on Authentication (Tom)

https://csrc.nist.gov/publications/detail/nistir/8344/draft

Tom: It has new meaning for some terminology (e.g, authentication) Requires strong identity proofing before you can have authentication, therefore you cannot have a DID method. Authentication shouldn’t depend on identity proofing.

Vittorio : NIST document may be meant to be interpreted in the context of federal activities. Tom : May be oriented towards what happens in federal government attestations. Would like to see DIDs are accepted in some government processes. NIST defines things for the federal government but people will pick them up because they’re well thought and bar is set high. But will result in mismatch between what NIST defines and the scenarios people apply them to. It’s better for NIST to clarify the context on how documents are interpreted.

Tom: Need to determine the scope of NIST.

Nat: Authentication happened long before identity proofing.

Tom: Federal government is also responsible for dealing with every citizen in the country, has other identification needs other than just federal employees. We want to get DIDs involved and NIST to recognize that, specifically self -issued identifiers. The definition of IAA (identify management authentication authorization) says that you need to perform identity management first before authentication. They should be unrelated and are separate matters.

David thinks it’s accurate. Depends on how identity management is defined (e.g. including full identity proofing). If you’re using a self asserted identifier and need to proof yourself, then authentication is the process of proving you’re the same person. If talking about full identity management, then DIDs might not be compatible.

In healthcare, we want to separate authentication from identity proofing and have them be in completely different processes at different times, and totally unrelated. Will make a use case so this concept is understood.

David: Strength of authentication and strength of identity should be orthogonal.

NIST seems to mix these and use loose wording in many cases.

Tom : Real concern is that they confuse credential service provider with identity provider.

Nat: There are many complaints about ISO 24670 using wildly different terminologies but that is due to it trying to delineate each act as functionalities into separate actors. So we need to talk more precisely.

Tom: Does OIDF issue recommendations for regulations?

Nat: Sometimes for technical ones, but not policy ones.

David: There is a difference between NIST and NISTIR like this one, so not sure if this is a proposed recommendation or not.

Tom: Could be pre-cursor to NIST 863-4

Tom will review the full document and send a review to the list.

Nat: OIDF periodically produces white papers or letters to communicate with technical committees on technical issues. OIDF could potentially do something similar with NIST. NIST used to head OIDF iGov WG in when they were producing SB863-3. iGov is defunct now so we may consider a letter.

4.   Drafts

4.1.   OpenID Connect Claims Aggregation (Edmund, Adam)

Adam and Edmund got together last week to discuss collaboration of OpenID credential provider spec and Aggregated claims spec:

Conclusion was that there is a lot of overlap and functionality between the specs. The goals of both specs are identical : allow holder/wallet/SIOP to acquire credentials/claims from a credential/claims provider and present them to a RP.

Decided to merge the specs into one and merge functionalities into credential provider spec.

Nat: As a process issue, aggregation claims spec is an adopted WG document, while credential provider is not. It’s easier to replace the contents of aggregation spec with new content and change the title.

Adam: Credential Provider spec is still in flux and need to work on some issues before beginning formal transition.

Main difference between specs :

  1. Semantic difference between endpoint names : credential vs claims endpoint
  2. Use of UID for request to endpoint vs cryptographically verifiable identifier which refers to the subject of the claims/credential
  3. Claims returned as verifiable credential vs JWT
  4. Credential provider spec allows for selection of format and credential so other types formats can be returned
  5. Claims aggregation allows downscoping of claims at endpoint

Adam/Edmund to file issues to file PRs for changes.

Kristina : Aggregate claims is using a claims parameter to request claims, does credential spec use this mechanism?

Adam : No, the credentials are returned straight from endpoint

Kristina would like to discuss this issue some more.

Nat: The description sounds more like distributed claims more than aggregated claims.

Adam: The model the spec takes is really separating out “credentials” and returning them from a separate credential endpoint, that has a “cryptographic binding” into the wallet/holder that is requesting them from them from the credential provider.

Edmund: It’s actually the aggregated claims method. The response are signed claims/credentials that the wallet/SIOP can hold onto and pass to RPs and not an access token and endpoint where the RPs have to go and fetch the claims.

Nat: How is request made to SIOP?

Adam: The request follows the same authorization code flow as OIDC with an additional scope “openid_credential” that requests access to the credential endpoint.The access token is then used to fetch actual credentials from credential endpoint.

Nat: Who operates the credential endpoint?

Adam: Existing OPs, credential providers.

Nat: That has privacy ramifications. It’s losing the AP/RP unlinkability.

Adam: The wallet is sending the request to credential provider and the request specifies the subject identifier that they’d like the credentials to be bound to. The wallet can present that credential onward to any RP. At point of issuance, the credential provider does not know where the credential is going to be provided to afterwards or if ever. The relationship is only between wallet and credential provider to procure the credential and wallet is responsible for where the credentials are presented to.

There are 2 relationships:

  1. Wallet and Credential provider
  2. Wallet and RP

Tom: Would like to see credential provider and the OP treated as completely separate roles but it’s OK if they’re co-located.

Nat: Credential provider is claims provider in aggregated claims spec. Not partial to the word usage of the term “verifiable credential”. Would prefer a more generic term like claims or attributes. Kristina and Tom agree also.

Kristina: Credential provider can issue VCs to the wallet/holder. When you’re presenting VCs, the holder is citing them that the VCs have been issued to the holder in the verifiable presentation (VP). Why do you need to bind them at issuance? Isn’t it duplicative?

Nat: From the aggregated claims point of view, you actually have to bind the credentials/signed claims to the entity who is operating (e.g. wallet). If there is no binding, then there is no authenticity for the claims to be bound to that entity.

Kristina: Understandable from aggregate claims model, but for VC/VP model already does that.

Adam: VP is a wrapper around the VC, proving you have control of the subject identifiers of those verifiable credentials. The verifiable presentation still needs to be cryptographically verifiable against the entity that's presenting those credentials. You still need that upfront cryptographic binding between the claims that are being presented, and the presenter.

Kristina: The subject DID is in the VC, right?

Adam: The proofs still need to be signed by the issuer.

Kristina: Yes, but it doesn’t need any new binding mechanism. What additional feature does a credential provider add to the VC/VP mechanism in terms of binding credential to holder?

Adam : There is nothing added. It’s just a mechanism to move the proof from the identity provider/credential/claims provider to the wallet. We're not changing anything with regard to proof format or data model. The scope is to get a set of claims, a credential that is associated with a cryptographically verifiable identifier from an IDP to a wallet. With regard to specifying which identifier, that's where the proof of control is required when you're sending the request to the credential endpoint. You're proving control over the identifier that you'd like to be the subject of the resulting credential being returned to the wallet.

Kristina: Cryptographic binding makes sense for aggregate claims model but not for VCs/VPs.

Nat : How do you establish the relationship between what the credentials provider or claims provider has, and what the wallet knows the user as?

Adam: There isn’t a standardized way. The VC model is really a data model for assertions about an entity.

Nat: One problem the aggregated claims draft addresses is how to bind the user at the SIOP to the user at the claims provider.They start off as completely separate entities. There needs to be some standard mechanism to bind them together.

Adam: That is the thought in credential provider spec as well.

Tony: The spec is too VC oriented, it should probably be split into a separate profile. Is the credential truly JSON?

Adam: Essentially, yes, it contains an identifier that is cryptographically verifiable, allowing the wallet through the holder to then present it onwards independently. The spec does not specify specific proof format. We're allowing it to be specified, either requested or defined by the credential provider, as to as to what type of approved formats that they support.

Nat: Issues will need to be created before creating pull requests for changing the aggregated claims document. This will allow these issues to have more discussion.

4.2.   NIST Ontology Use case (Tom)

The is the idea of object management with an object and an identity.

Assuming the object is a cell phone, you get an app on the cell phone and you get a certificate for it.

That becomes a JWT. To make it useful, you need to bind the JWT with a user through a registration process. Also bind it to a proof of presence when you send it back.

The final verifier gets a object, certificate bound together with a proof of presence. And the whole thing is another certificate. The claim can be a JWT.

Nat: Aggregate claims specified in OIDC is exactly like that.

5.   Special Calls Status

5.1.   SIOP Special calls (Kristina/Tim)

Planning to discuss adoption of the SIOP v2 draft and go though issues to make decisions.

6.   PRs

  • pull request #5 - editorial changes for aggregation spec

    • approved and merge

  • pull request #9 - SIOP v2

    • Clarified scope
    • added request_uri parameter for backwards compatibility reasons
    • Feedback and editorial changes

    Will discuss next week

8.   AOB

The meeting was adjourned at 24:01 UTC

Updated