1.   Roll Call

• Attending:
  • David waite
  • George Fletcher
  • John Bradley (OIDF/Yubico)
  • Joseph Heenan (Authlete / OpenID Foundation)
  • Kristina
  • Roland Hedberg
  • Tom Jones
  • Adam Lemmon
  • Andrew Hughes
  • Bjorn Hjelm (Verizon)
  • Edmund Jay
  • Tim Cappalli
• Regret:
• Guest:

2.   Adoption of Agenda (Nat)

• Federation Spec entity listing API
• Federation nsigned request for automatic client registration

3.   Federation Spec entity listing API

Listing API allows listing of a Federation entity’s subordinates

List can be large, possibly thousands.

Can cause problems on limited capability devices

Proposal for limiting results by

• Paging
  • Server has to keep state
• Filters

How likely is a mobile device to access the entity listing API?

SIOP use cases

Tom proposed that the request should have a query parameter 2.5 years ago which was rejected

Query parameter will contain a regular expression

This would allow a client to query for a registration that would allow access to a certain entity

Not allowing listing would preserve privacy

Should probably protect this endpoint with a token or password or use in Trust Anchor Federation model

Listing might be useful for administrative or operational capabilities.

Or listing DID methods supported by a particular entity

The query parameter would allow you to get the full entity statements of the entities that met the criteria

David disagreed that this is needed for normal operation, but agreed that it’s valuable as another feature.

Tom would send his original proposal to Roland.

Currently, the list returns list of entity IDs

Tom’s proposal returns the full entity statement

Whether this resource is protected or not needs to be considered.

Might have to consider whether the client is logged on to a federation or to an endpoint.

Having API access is separate from a user having access to do login based on results of list.

Sensitivity of results needs to be considered so there is also a need for an authorization model.

Bearer tokens, DPoP or other sender constrained tokens can be used but might make interop difficult.

Complex queries are not part of the API, only descendants of entities that are part of the organization.

May need to divide this problem into current API and new API features.

Tom stated that creating a statement about how you construct a query parameter can be applied to anything irrespective of the lower level API.

Possible filters:

• Entity name
• Country
• Anything in the DN

Filters need to be related to the API data model, but Tom prefers a more generic proposal

Also 2 possible results

• Entity name
• Full entity statement

Tom’s original goal was for a list of entities that meet a criteria

For the current model, you get a list of entities and then you interrogate those entities to get their entity statement

Look into another API that combines the steps.

Tom will send out his proposal.

4.   Federation nsigned request for automatic client registration

Public RP clients have different trust model. They do not have access to do signed requests.

Public clients do not have private key material in the entity statement.

Also not able to verify public clients.

iOS and Android app attestations can be used for public clients to verify authenticity

OAuth 2.1 working on credentialed clients that are between public and confidential clients

DCR with mobile app attestation might mitigate some mobile app impersonation problems.

Look into profiles or other mechanisms to add to best practices for native apps to make registration better.

Beginning to get more tiers of clients, so do we need to write new specs for them?

There are 2 levels

• Plain software statement
• Making sure the app meets attestations

But, having attestations is different from unsigned requests

Having app attestations as part of normal message flow might go better under OAuth

For attestations, need a challenge to be signed instead of the attestation itself so it’s not fraudulently replicated

Software statement only states that it might be a certain entity, but doesn’t say it is really that certain entity.

For native app automatic client registration to be done properly, it should use the Software Statement and the software statement should have the information about what the hash of the public key of the developer is, or whatever is required to validate, a particular SafetyNet attestation or app equivalent.

5.   AOB

The meeting was adjourned at 15:02 UTC