[Openid-specs-ab] Spec Call Notes 6-Jun-19

Chuck Mortimore cmortimore at salesforce.com
Thu Jun 6 18:04:41 UTC 2019


We've looked into sign in with apple a bit, and it appears to largely be
openid connect.  A few things of note

   - client_secret is actually an ES256 JWT rather than a shared secret.
    They did not use RFC7521 format for that.
   - there doesn't appear to be a userinfo endpoint
   - there's a step where you need to download a signed artifact and host
   it under .well-known for domain verification


On Thu, Jun 6, 2019 at 10:33 AM Mike Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Spec Call Notes 6-Jun-19
>
>
>
> Mike Jones
>
> Nat Sakimura
>
> Bjorn Hjelm
>
> Brian Campbell
>
> Rich Levinson
>
>
>
> Login with Apple
>
>               Apple announced Login with Apple this week at their
> developer's conference
>
>               Nov Matake has created a Ruby gem for it, and so knows the
> ins and outs of the protocol
>
>               Apparently it is Connect-like but not exactly Connect
>
>               Nat and Mike have asked Nov if he could summarize how it's
> the same and different
>
>               Mike found this after the call
> https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple
>
>               Dick Hart pointed out new app store requirements to use
> Login with Apple on Twitter
>
>               https://twitter.com/DickHardt/status/1135769039043563520
>
>
>
> Authentication Failed Error Code Draft
>
>               Mike sent in a review
>
>
>
> OpenID Connect for Identity Proofing
>
>               Mike sent in a review
>
>                            The most important comment was to make it about
> verified data - not just verified person data
>
>                            Verified person data can still be covered by
> the draft
>
>               Nat: It's always good to have a general thing - then you can
> profile it to meet your specific requirements
>
>               Tony wrote that we should align with ISO 2903
>
>               We should also look at the EU minimal viable KYC document
>
>                            PRIORITY GROUP 2 PROPOSAL FOR AN
> ATTRIBUTE-BASED & LoA-RATED KYC FRAMEWORK FOR THE FINANCIAL SECTOR IN THE
> DIGITAL AGE
>
>
>
> EIC
>
>               The OpenID workshop was very well attended
>
>
>
> Transient Subject Identifier Type
>
>               Davide Vaghetti wrote a document on this
>
>                            See
> https://gist.github.com/daserzw/813023b4e1c04d09beb732ef00d7c9e9
>
>                            People should review his proposal
>
>               There's a mailing list discussion on whether RPs need to be
> dynamically told that the subject is transient
>
>               Some banks are using the transaction ID as the subject,
> which is problematic
>
>                            Apparently the banks are reluctant to provide
> user identity
>
>                            It's especially problematic when people have
> multiple accounts
>
>                            Brian stated that the Open Banking use case was
> intended to be pure authorization - not identity
>
>                            This has been discussed in the FAPI working
> group
>
>               We should explicitly describe the "sub" lifetime
> expectations in Connect Core
>
>                            Nat filed the issue #1096 - Core - Section 8.
> Need more subject_type
>
>                            Nat gave the example that passports use
> time-bound identifiers
>
>                            Nat said that age verification is a possible
> use case for ephemeral identifiers
>
>               Nat said that identifier unlinkability is described in ISO
> 27551
>
>
>
> EAP
>
>               We're in the public review period for the two EAP specs
>
>
> https://openid.net/2019/04/22/public-review-period-for-two-proposed-eap-implementers-drafts/
>
>                            People are encouraged to review them
>
>               Voting was started
>
>                            However it was blocked by a Ruby application
> error
>
>                            Mike will have Nov Matake investigate
>
>                                          It turns out to have been caused
> by a Rails version upgrade, which Nov fixed
>
>                            The voting period will need to be rescheduled
>
>
>
> Open Issues
>
>
> https://bitbucket.org/openid/connect/issues?status=new&status=open
>
>               #1093 - Extensibility: how do we support extensibility for
> trust frameworks, evidences, verification methods and id documents?
>
>                            Mike will comment on registries, OpenID, and
> IANA
>
>               #1094 - How to treat unknown identifiers in claims parameter
>
>                            In general, we ignore not-understood values
>
>                            If a value is required and not understood, and
> appropriate error can be returned
>
>               #1095 - Registration - 3 - rotate/renew secret
>
>                            RFC 7592 can be used to do this
>
>               #1096 - Core - Section 8. Need more subject_type
>
>                            Mike commented about the existing subject types
> being persistent
>
>
>
> Next Call
>
>               The next call is Tuesday, June 11 at 4pm Pacific Time
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190606/6e9e89b2/attachment-0001.html>


More information about the Openid-specs-ab mailing list