DO NOT MERGE: Craig's draft for v1.2 - still has work that should be brought across into 1.2#47
DO NOT MERGE: Craig's draft for v1.2 - still has work that should be brought across into 1.2#47cdvoisin wants to merge 1 commit into
Conversation
Introduce Self-Contained Passports
kwrodarmer
left a comment
kwrodarmer
left a comment
There was a problem hiding this comment.
This is a great move in the right direction. There are probably some things I will contribute afterward, but let's take this as the new base.
davidbernick
left a comment
davidbernick
left a comment
There was a problem hiding this comment.
This is exactly what we've been discussing -- no objections from me.
|
|
||
| 3. A Broker MAY issue [Self-Contained Passports](#term-self-contained-passport). | ||
|
|
||
| 1. Self-Contained Passports MAY be large and are only for use via POST within |
There was a problem hiding this comment.
Items 1-3 are not requirements for brokers, restructure?
| GA4GH-compatible service endpoints. | ||
|
|
||
| 2. Self-Contained Passports MUST NOT be used with OAuth2 endpoints that require | ||
| an `Authorization` header. |
There was a problem hiding this comment.
Not even if something else than the self-contained passport (for instance, a regular OAuth2 access token) is placed to the Authorization header?
|
|
||
| { | ||
| "ga4gh_passport:self_contained_v1": "<self-contained-passport-jws>", | ||
| "targets": { |
There was a problem hiding this comment.
What is the benefit of allowing several targets in one request vs. sending several requests each with one target?
|
In ver 1.2, do we want to introduce a mechanism (potentially based on RFC8707) to request a downscoped passport from a broker so no root passport becomes exposed to a client? |
|
These are great questions, thanks for reviewing and your suggestions. Let's
take a lot of the feedback into the AAI/Passport discussions on Thursdays
and see what will work given a set of community requirements like those
coming from NIH.
…On Fri, Aug 6, 2021 at 8:07 AM mikael-linden ***@***.***> wrote:
In ver 1.2, do we want to introduce a mechanism (potentially based on
RFC8707 <https://datatracker.ietf.org/doc/html/rfc8707>) to request a
downscoped passport from a broker so no root passport becomes exposed to a
client?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#47 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKEDCSG5R4ZJIV7D5YEBYC3T3PGAZANCNFSM5AUETVVQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
How is the in the Passport Endpoint Response different from the regular ga4gh_passport_v1 claim received from /userinfo? |
| Where: | ||
|
|
||
| - `tokens`: REQUIRED as the map of tokens per `aud` in the request structure | ||
| and each `<self-contained-passport-jws>` is a JWS Compact String of a Self-Contained |
There was a problem hiding this comment.
Would need to specify the claims within the and how it is similar or different than what is returned from the /userinfo endpoint. For example, it has the visas but doesn't have email, picture, given name, etc.
There was a problem hiding this comment.
If the Passport endpoint response is 1:1 with the ga4gh_passport_v1 claim from /userinfo, why do we need this new endpoint?
There was a problem hiding this comment.
- It is designed to remove the need for bearer tokens to call back to /userinfo by issuing embedded tokens. More on requirements in the design doc.
- It is designed to be the mechanism to be leveraged to support visa downscoping, not yet shown in this PR. However there are other endpoints and mechanisms being explored in the design doc.
- It may offer a different set of claims than /userinfo to not expose as much PII. Once again, there may be other ways to control this using scopes.
Therefore, it is not clear if this PR currently has the right approach, and so this PR so far is for discussion on what such a self-contained passport minting endpoint might look like by exposing more details of how it translates into spec, but these design issues need to be resolved before creating or updating a PR like this to be ready to land.
|
Are there going to be updates to the embedded access token (i.e. visa) polling section? I believe the RAS implementation has departed a bit from the spec in this respect by implementing a separate endpoint for visa (or even passport) validation and am wondering if that will be the approach in 1.2 as well. |
|
Yes this 1.2 PR is likely not valid from what’s being discussed now (4K
passports)
…On Fri, Sep 10, 2021 at 3:54 PM dvoet ***@***.***> wrote:
Are there going to be updates to the embedded access token (i.e. visa)
polling section? I believe the RAS implementation has departed a bit from
the spec in this respect by implementing a separate endpoint for visa (or
even passport) validation and am wondering if that will be the approach in
1.2 as well.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#47 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPYAMNVNGZSS6UPXU3MROLUBJO7XANCNFSM5AUETVVQ>
.
|
andrewpatto
changed the title
5 participants
Introduce Self-Contained Passports