1.   Roll Call

• Present: Nat, Bjorn, Chris Phillips, George Fletcher, Roland Hedberg, Tome Jones, Rich Levinson, Brian Campbell
• Regret: Mike

2.   Commonalities and Differences Report on Fed Specs (Andreas/Roland)

Was a bit more work than expected. Andreas sent an email to the list to the link of the current draft. * https://github.com/rohe/oidcfederation * https://storage.googleapis.com/openid-connect/oidcfed-05.html

See also:

• http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20181008/007033.html

Finished with basic requirements such as : #. collecting trust chains/trust paths, and validation. #. How to compose the complete the metadata from different pieces of metadata.

Andreas and Roland each have implementations which can publish complete paths and collect and validate. They can cross verify each other's implementation.

The spec has 2 ways of doing client registration"

1. Implicit - Don't register, just use published values to the federation as registration data. The OP will either accept it or not.
2. Explicit - Similar to OIDC registration. RP publishes what it want's to register and OP responds.

Add new endpoints for discovery and registration and also has signed requests/responses.

• It's a generalized spec which can be used for other specs.
• No roadblocks so far.
• Would like more reviews and feedback.
• Topic can be raised at Internet2 Tech X next week.

Research and Education WG has been accepted. Do you see that work will go under R&E or Connect A/B? * Generic version of spec should be done in A/B group.

Tom : There is a new proposal in Kantara Initiative to create Federation group.

• Need a way to take registry information and spread it to the community of participants in the federation.
• Will be using the spec for this purposes.
• Will try to provide feedback.

OIDC Federation spec talks about implementation aspects (validating circle of trusts).

• Doesn't talk about what Federation operator has to do.
• That's what the Kantara group is trying to do.

3.   Issues

#1051: The role of non-standard scopes

Everyone that has worked with OIDC has assumed that there will be non-standard claims added to the userinfo response. Together with this it's reasonable to assumed that we will also seen non-standard scope values that like some of the standard ones (profile, email, ..) can be used to request that a specific set of information should be available as Claim Values.

With that in mind the sentence 'Using the claims parameter is the only way to request Claims outside the standard set.' at the end of section 5.5 is obviously incorrect.

• Sentence should just be removed.
• Assigned to Mike

#1052: make clear that nonce is always required for Hybrid flows

Assuming that that nonce is always required for Hybrid flows no matter where the id_token is returned from, also following: https://github.com/rohe/oidctest/issues/111#issuecomment-426450954 In section 3.3.2.11. ID Token for the Core spec, https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken, it describes the ID token in the Hybrid flow, which says

• 'Code' and 'Code Token' flow doesn't require nonce in ID TOKEN in backchannel.
• A new certification test has been added which differs from previous certification tests.
• Agreement on call is that if a nonce is in the request, ID Token response should have nonce no matter where it's returned
• Discussion on this issue should continue.
• General consensus is that ID tokens should be consistent no matter where it's returned.
• Errata should only clarify, would be serious and problematic it it introduced breaking changes.
• Mike has checked in some breaking text.

#1050: Extra claims from a claims provider

In section 5.6.2.2 in the example src1 is defined to return 2 claims (payment_info and shipping_address). This even though the example stipulates that src1 has 3 claims (shipping_address, payment_info and phone_number). This brings up the question about what to do if a claims provider returns more claims then listed in the response from the OpenID Provider. Are the RP expected to ignore the extra claims ? Or just add them to the original response ?

• RP Should ignore if didn't ask for it.
• George asked question whether OP should only returned asked for claims.
• Yes, OP should only return asked for claims per data minimization principle.
• George will create a new issue for that

It has been 5 years since ratification of OpenID Connect 1.0.

• Will solicit feedback from community if revision necessary.

4.   Token Binding (John)

Token Binding was announced as an RFC.

5.   Event

• IETF 103 Bangkog - Brian
• IIW - Ask VMWare for remote bridge

6.   3. AOB