OIDC Deployment Working Group

[Nick Roy <>]

Here are my notes from this meeting:

OpenID Foundation meeting at VMware 10/22/2018
https://openid.net/2018/09/07/registration-open-for-openid-foundation-workshop-at-vmware-on-monday-october-22-2018/

Intro - Don Thibeau
Real estate standards org in the US has built a test suite on top of OpenID 
Connect.
JanRain is joining the OpenID Foundation and working on self-certification.

OpenID Connect WG - Mike Jones
Form post response mode - analogous to the SAML SSO POST flow
Current work
        - Federation specification
                - (Roland will cover)
        - Session management / logout
                - Three different ways to log things out. Would prefer there 
was only one but there are different use cases.
                - Working to take these from ID to final status
        - Second errata set
                - Doesn't make normative changes. Corrects typos
                - Waiting for OAuth AS metadata spec to be final
        - Related work
                - International Gov (IGov) - requires support for encryption
                - EAP
                - Certification
Open conversation - how are you using it and what would you like to see the 
working group do/know?
- High quality RP libraries (Google - work donated to OIDF) - Roland produced 
the python library; Java/Javascript libraries in development
- JWTconnect.io - links to the contributed libraries
- iOS increase for 'intelligent threat protection' to try to prevent cookie 
leak to third parties. Unfortunately SSO cookies look a lot like tracking 
cookies. Letter was sent to Apple saying 'you're breaking OIDC, SAML, SLO' - 
Apple says 'we're not fixing this'. Vittorio will do a session on this at 
IIW. Existential risk to federation on iOS. This is specific to Safari. 
Includes all web views - if you are redirecting through a domain at login 
time, Safari will delete these cookies much sooner than it had in the past. 
Apple made it difficult to get tokens for native apps - if you try to 
bootstrap an application with a native identity, it's hard to share that 
identity with other apps on the device.
- Enhanced Authentication Profile (EAP) WG
        - IETF token binding specs with OIDC to protect authentication tokens
        - Allows you to protect bearer tokens with proof of posession over TLS
        - Also includes how you use acr values to signal strong authentication
        - acr:phr - phishing-resistant
        - acr:phrh - phishing-resistant/hardware backed
        - Taking this to implementer's draft status
- OpenID Certification
        - Two components: 1) technical evidence that you ran the tests and 
passed 2) legal certification that you did do that
        - Certified implementations can use the 'OpenID Certified' logo
        - Five profiles for OPs and corresponding profiles for RPs
        - New addition to the test suite: Form POST response mode
        - RP tests are free because we want help testing the tests
        - Hans Zandbelt built the form POST repsonse mode test
        - 187 OP profiles certified for 61 implementations by 51 organizations
        - 54 RP profiles certified for 20 implementations by 16 organizations
        - Most of the test developers are European
        - Testing logs are made publicly available for scrutinization; org 
puts its reputation on the line by making a public declaration that its 
implementation meets the requirements of the profile that it certified to
        - Not a profit center
                - Member price is $200
                - Non-member price is $999
        - How this relates to interop testing: OIDC did 5 rounds of interop 
testing; with interop testing, by design, participants can ignore parts of 
the specs. Certificaton raises the bar: Defines conformance profiles and 
assures interop across the full feature sets in the profiles.
        - You can use the certification suites for interop testing, and it's 
free to use. Only charged when you submit a formal certification claim.
        - What's next:
                - Refresh token behaviors
                - Session management, front-channel logout, back-channel 
logout
                - OP-initiated login
                - Additional documentation from Roland and Hans
                - Certification for additional profiles: HEART, MODRNA, IGov, 
EAP, FAPI, etc.
        - Session management / front-channel logout / back-channel logout
                - Separate profiles for all three types
                - Logout OP Test Functionality
                        - Discovery metadata values
                        - All three profiles use RP-initiated logout with 
post_lout_redirect_uri values
                        - Test whether logged out with prompt=none request
                        - Test state
                - Logout RP Test Functionality
                        - Registration metadata values
                        - RP-initiated logout and post_logout_redirect_uri 
values

OpenID Connect Federation - Roland
        - See my notes from ACAMP at TechEx18
        - Draft: https://storage.googleapis.com/openid-connect/oidcfed-05.html
        - Roland almost done with implementation - by end of week


FastFed WG - Darin McAdams, Amazon
- Darin mentioned InCommon as an example of a high assurance federation
- This WG wants to do federation B2B in an easier way
- Invented at IIW in the spring
- AWS, GCP, SalesForce, ADP all working on this
- FastFed Core 1.0 ID 1 - will be a FastFed meeting at IIW on Thursday, 2-5 
p.m. Boole room
- Federation is hard/slow. Want to reduce the number of steps you have to 
take. "You definitely know what technology you're using in the enterprise 
market, because you just spent 4 weeks integrating it."
- Why not just use dynamic registration?
        - A lot of cloud IaaS are multitenant (extra discovery hurdle)
        - Handling different schemas/provisioning modes
        - SAML is the dominant protocol in the enterprise world, but no 
agreed-upon schema (I laughed)
        - They are once again reinventing SAML federation and IdP discovery
        - It is, however, multiprotocol, which is nice
        - Allow you to specify stuff like where your SCIM endpoints are, etc. 
for preprovisioning
- Open issues
        - Discovery is hard and email addresses aren't good at bootstrapping 
it, webfinger a bad way to do discovery (I LOLed again)
        - Turns out hosting OIDC discovery at a domain like amazon.com is 
hard because the enterprise IT team has to get through the product team for 
amazon.com. Don't want it on the retail-facing website!
        - Might want to use a third party IaaS
        - Interested in subdomains for webfinger discovery
        - If I'm using a third party, I can create a CNAME to front the 
fastfed discovery stuff
        - Schemas and provisioning
                - "There is no schema in SAML" (I LOLed)
                - Too many schemas - OIDC for SSO and SCIM for 
preprovisioning - which schema to use?
                - How to bind into SAML or OIDC messages?
                - OIDC is JIT only
                - Want enterprise user extensions

Financial-Grade API - Bjorn Helm, Verizon
- Focus of the foundation in 2019
- Open banking development in the UK requires institutions in UK to open up 
their APIs to allow third parties to interact with users and their accounts
- Joint announcement between OIDF and UK open banking initiative to use the 
OIDF standards and test suites as a way to implement and measure those APIs
- US FS-ISAC has adopted parts of the FAPI
- Australia will likely adopt as well
- Read-only and read-write profiles recently released for open review, the ID 
voting runs through today (approved as of noon today)
- New JWT-secured Authorization Response Mode (JARM) ID being worked on right 
now - signed authorization response (mirrors JAR, but doesn't require OIDC), 
will bring to OAuth WG at IETF

IGov - Bjorn Helm, Verizon and Paul Grassi, ???
- Paul Grassi leading the effort
- Federated access to public services profile
- IGov profile
- Out for a vote for ID status right now - about a week and a half in to the 
45 day review period
- Next steps:
        - Attribute metadata specs
        - Vectors of trust use cases (VoT is through the IETF standardization 
process now)
        - Implementation
- Why metadata?
        - Limitations in assurance levels
        - Existence of use cases
        - Existence of specifications (NISTIR-8112)
- Issues with adoption
        - Commitment to SAML in US gov
        - Lack of governance
        - No enforcement
        - Trust framework services in doubt
        - Lack of agency awareness in technology, standards, commitment, IAM, 
voting, etc.
        - No one knows what "NIST-approved" means (that sounds familiar)
- Opportunities
        - Federal student aid loan processing RFP includes identity
        - IT modernization
        - SSA transformation
        - IRS transformation

MODRNA - Bjorn Helm, Verizon
- Support GSMA technical development of Mobile Connect
- Enable mobile network operator to become an OP
- Develop a profile of and extension to OIDC to be used by MNOs to provide 
identity services
- Lots of mobile network/vendor participation
- Mobile phone number as user identifier
- Mobile phone as authenticator
- MNO as OP
- Replace passwords and hardware security tokens
- Intent to own the post-shopping-cart payment process
- Portfolio roadmap - User questioning is an enabler for mobile connect, that 
is a roadmap item for this year
- GSMA is pursuing enabling token-binding support via mobile connect
- Reference architecture (slide) - use API Exchange for RP to request 
authenticating operator
- Developing discovery, account registration, authentication request, 
authentication profile
- Majority of the authentication has been adopted by the mobile connect 
specification
- Developed a User Questioning API as well as a specification for account 
porting - allows moving the mobile connect account from old to new OP
- Client initiated backchannel authentication (CIBA - kind of like SAML ECP) 
- in collaboration with financial-grade API (FAPI) WG
- Project Verify is a brand name for a service that is the output of the 
mobile-based authentication task force. Create a common workflow to allow a 
service provider to onboard an MNO OP for attribute verification, MFA, 
step-up authN, etc. Know what your location is when you authNed, etc. 
Leveraging OIDC for the interfaces to RPs. Using MODRNA discovery profile. 
AuthN is OIDC core with some attributes from MODRNA authN profile and some 
from mobile connect specifications. Operators were involved in an NSTIC pilot 
around this in 2012-2013.

RANDE - Nick Roy, Internet2
Slides: 
https://docs.google.com/presentation/d/1vd08a5OLsJOOXpoxbqua-wO-v5OMGZjf9L_d-mO9HUk/edit?usp=sharing
Torsten Lodderstedt noted that we need an OpenID AS federation as well for 
things like protected API access. Also he noted a shared need to do AS 
discovery which we should work with him on in the banking / FAPI work

RISC - Adam Dawes, Google
- Account compromise cleanup
- People's identities are all linked - people use a public identifier like 
email address to signal this identity
- That is used as a means to recover accounts
- If a given IdP (say, a giant one creating email accounts) is compromised, 
it can lead to compromise of lots of other accounts
- SSO doesn't close the loop on user safety
- Users can't evict an attacker from a session bootstrapped with SSO
- Single sign-out not desirable - abrupt logouts for RP/OP, lots of chattery 
state checks which don't scale for the IdP
- Need to share important security events across providers
- How do you share that information safely? Only sent to the apps the user is 
using.
- How do we know the user's apps? Explicit relationship via OAuth; Implicit 
relationship registered via API (requires contract between the OP and RP)
- IETF secevent status
        - RFC 8417 submitted to IESG for publication in July 2018
        - Defines a SET (security event token)
        - Delivery (push? poll? etc.) draft-ietf-secevent-delivery
        - Management API (moved into RISC profile)
        - RISC specs: OIDF bitbucket, approved as ID
        - RISC events
                - (lots)
        - OAuth events
                - (several)
- Implementations
        - Google live transmitter with explicit use case
        - Implicit use case (in progress)
        - Amazon (in progress)
- Next steps
        - Branding and naming
        - Sync of past events upon setup (example: abusive/bot accounts)
        - IETF drafts
        - Interop - Q4 2018 Google to open explicit support, Q1 2019 Google 
to open up implicit support
- Not going to use the Account Chooser flow ("fast IDV") to bootstrap RISC 
because a lot of RPs don't use it, and it can prompt login to Google if the 
user isn't already logged in, which is confusing. Want to send users through 
a more explicit flow to register users for RISC. When users go through the 
fast IDV flow, Google doesn't do consent because the RP already had the info, 
and they don't track the request/generate a token.
- Question: Have you considered zero-knowledge algorithms for sending SETs?
        - Has come up a few times, but the registration is positive between 
two parties about a third (the security subject). Relying on SSL, there are 
also options to do encryption with the SETs that can be used.
        - Interest from Microsoft as well
        - Interested in working with the R&E community on this as well

Other random stuff:
- Torsten Lodderstedt noted that banks have to collect know your customer 
(KYC) data which could be used for bootstrapping assurance, but it is missing 
claims like nationality/place of birth.
- No real mechanism to assert level of confidence for different claims, needs 
to be a way to represent that
- Recipient of the data needs evidence about how the IdP verified the 
identity - he will propose a session on this at IIW


> On Oct 22, 2018, at 3:22 PM, Nick Roy 
> <>
>  wrote:
> 
> Here is a link to the slides I presented today, at the OpenID Foundation 
> workshop:
> 
> https://docs.google.com/presentation/d/1vd08a5OLsJOOXpoxbqua-wO-v5OMGZjf9L_d-mO9HUk/edit?usp=sharing
> 
> Best,
> 
> Nick