Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Built Explore the source changes : Inspect the deploy log : Browse the preview : 
 Section 2.2 is currently called : Then the text continues with : This means that this section is currently restricted to the RO . Since this call is restricted to the RO , the title of this section should be changed into : Requesting RO Information . In addition , the reason(s ) for requesting such information is not mentioned and should be explained . As a side - consequence , a user has no on - line means to know which personal data the AS knows . This comment also impacts the content of section 1.4.6 ( Requesting User Information ) . This topic has been first addressed under the issue which is still open . It would be wise to allow such an on - line access so that the user can know which attributes are known by an AS and then choose which attributes to insert into an access token . 
 Maybe we 'll need a bit of rewording , although I 'm not sure the proposed changes help so much . I just think we should put more emphasis ( and state early on ) what is shortly described at the end of section 4 , i.e. that here RO = end - user 
 RO = end - user is not the general case . The usefulness of supporting Requesting RO Information is not crystal clear and should be indicated , but there is an interest to support Requesting User Information . While I agree with you that " we 'll need a bit of rewording " , simply stating that RO = end - user in section 4 will not solve the issue . 
 I notice that states It also shows that there is no RS involve and diagram uses label : User ( not RO ) To my understanding End - user is " logged in " to the client instance . Given role definition : If we do n't have RS involved , so we also do n't have any Protected Resource here , does it really make sense to speak of Resource Owner ? 
 Yes , that 's why we talk about the " user " here . Notice that currently , this term is used when we do n't know the exact role it will play in the protocol ( end user or RO ) . 
 If that 's the case for why does speak about Resource Owner ? Again in 2.2 we also do n't seem to have Resource Server or Protected Resource involved . 
 The rationale is : in the intro of section 4 , gnap allows a large variety of cases . GNAP can handle UMA2 types of scenarii ( hence 1.4.6 and a few other places ) but in gnap core we mostly detail the case where end - user = RO . Hence what we explain about the subject , and it makes sense to limite the diffusion of confidential information about the RO ( the most limiting case , hence 2.2 and a few other places ) That 's actually a quite subtle difference , but i think it makes good sense . 
 Given above definitions maybe it would make sense to broaden definition of RO to : subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon . Since in the User acting as RO does n't grant or deny operations on resources ( served by RS ) but only grants / denies obtaining an assertion . 
 I agree that the specific language that references should be tightened up . What 's a little awkward right now is that  's language treats access to an RS and access to information contained in assertions as protected resources , but it does n't do so particularly cleanly due to several major text revisions that have changed things a little out of sync with each other . Both data from an  ( using an access token ) and assertions / identifiers passed to the client are targeted at the client itself , so in that way they 're the same nature , a protected resource after a fashion and both controlled by an RO of some kind . What 's different is that the info passed back directly is usually assumed to be : about : the end - user , because that 's what the client is calling about in just about all the use cases that are known . Technically all of the information , either from an RS or subject information passed directly , is controlled by the RO . The end - user can get involved through interaction and act as the RO . The case where the RO does n't equal the end - user is useful in many situations but leads to unexpected weirdness when you 're talking about the subject information coming back . 
 Fair point . We might start by listing what needs to be changed . 
 I tend to think of the AS as having a separate service endpoint for RO requests because they are the ones that can edit AS policy . A service endpoint that is accessible to End User requests would be " separate " and could be used by anyone including the RO when they want the protection of least - privilege . This distinction may be unhelpful in the general case of explaining  so I do n't mean to overstate it . 
 when you say " service endpoint " are you thinking of something that 's interactive and user - facing ( so a webpage ) or something that 's a callable API ? 
 I really do n't know enough to answer purely technical questions . I think mostly in terms of privacy engineering and look to this group for security and devops perspective . Therefore , I focus on the AS as the primary , if not the sole , entity that stores and executes RO policy . The AS takes requests and turns them into access tokens . The requests might be via ( RAR ) API or a web form . Either way , this request interface is likely unsecured . Some requests present credentials while others might add an authentication flow . That begs the issue of how did the AS get the RO 's policies to begin with , long before a request comes in ? I would define whoever sets the AS policies as the RO ( regardless of any particular RS - RO relationship ) . A so - called " policy manager API " has been under discussion in UMA for about a year because at least one implementer wants to author policies on a mobile app and standardize the way they are uploaded to the AS . Back to Justin 's technical question , I 'm trying to implement the shortest distance between OAuth 2 and GNAP in a way that I can understand and explain to others . I 'm doing this in FastAPI ( because I do n't know much beyond elementary Python , because it has built - in OpenAPI documentation , and has some OAuth 2 and JWT functionality ) . I 'm deploying ( automagically ) to DigitalOcean App Platform in order to be clear about my various security and build shortcuts . I 've designed the demo as two separate FastAPI server domains for the RS and AS . A " global " CouchDB instance is deployed for RO policy storage and any state that needs to be saved as part of the protocol demos . -- ( the AS ) and running at https://ognap- -- and running at https://ognap - rs- -- The protected resource is going to be _ just a self - verifying vaccine credential ( I invented ) -- -- Some of this is running at I 've been stuck trying to answer Justin 's exact question for quite a while . I think I need to set up the AS ( OGNAP ) to deliver a PWA to the RO so they can edit policies locally in PouchDB and sync the polices with the CouchDB the AS can access when a request comes in . That forces me to learn or something like it . Aside from my long - term goal to upgrade the HIE of One Trustee demo from UMA to GNAP , I 'm also hoping to show the W3C and DIF protocol groups how easy it could be to mitigate significant OAuth 2 human rights concerns using GNAP . Any suggestions , help , moral support would be really welcome . 
 back to and : looking again on this . I guess we could define what we mean by operations . Getting an assertion is an operation , in my view . Or give it as an example . What do you think ? 
 I think it comes down to whether or not we consider the " subject information " , which includes both identifiers and assertions , to be " resources " or not . I always thought they are , but they are definitely a different style of resource than what comes from the RS so maybe we need better wording around it . We talked about it a bit in the long terminology discussion a year ago , but I do n't think we ever really landed on a term that fully captures " stuff sent directly to the client by the AS and not accessed through the RS " . Identifiers and assertions are the two categories where there 's clear demand , but other things could happen through extensions as well . 
 Does this issue also have to align with authentication flows that build on GNAP ? a subject presents a DID or other identifier to a relying party ( RP ) the RP dereferences the identifier to an AS they trust a request for assertion is made to the AS the AS issues a liveness challenge to the subject the AS returns an assertion and attributes to the RP ( the attributes might be accessed indirectly via an access token returned with the assertion ) How is SIOP planning to handle this ? 
 In the current draft , section 2.2 : " The AS can determine the RO 's identity and permission for releasing this information through interaction with the RO ( Section 4 ) , AS policies , or assertions presented by the client instance ( Section 2.4 ) . If this is determined positively , the AS MAY return the RO 's information in its response ( Section 3.4 ) as requested . " Currently , a resource is just a short cut for " Protected resource " , which really refers to an API served by a RS . So we have a mismatch ( or at least a missing case ) in the RO definition ( as pointed out by and I 've tried some sentences to specify subtypes for resources , but it becomes very confusing . The proposal by to define the RO as " subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon . " seems slightly incorrect to me , because the assertion is not made by the RO , but by the AS . What the RO grants to the AS is access to its attributes ( and then the AS may carry out further due diligence to derive assertions , for instance through AuthN flows as suggested by The decision to disclose or not its own attributes is not restricted to the RO , it 's actually something under the control of every subject . So here 's what I 'd suggest to solve the issue ( new part in bold ): update the definition of " Subject : person , organization or device . It decides whether and under which conditions its attributes can be disclosed to other parties . " question 1 : should we limit this to physical persons ? ( from a legal perspective , that makes sense , but then would n't an org want to restrict what it shares , cf issues around data sovereignty ? ) . I think the principle could be generic . question 2 : I 've under which conditions because we already discuss that in the text ( manual consent , automatic policy , etc . ) , plus it 's not only a yes / no , it also concerns what those other parties can do with it , including further sharing those attributes , cf the case mentioned by where the AS sends them to the RP . Feedback welcome ! 
 section refers to the Subject exclusively as RO . I 'm still uncertain if the subject who in interaction only decides to disclose some attributes in an but not any " Protected resources " ( an API served by RS ) is considered to act as RO . If that 's the case what would be the case where the subject decides to disclose some attributes but does n't act as RO ? 
 I 'm not entirely sure about the use case you 're targeting here . Could you be more specific ? 
 Maybe I should n't have mixed two questions together . Let 's focus on one of them first . section always refers to the Subject as RO . In your previous comment you mentioned that : When we would have a situation where a Subject is deciding to disclose its own attributes but they do n't act as RO ? 
 In theory section 4 allows other situations ( at the beginning of the section ) . But the only case that 's detailed is the case where it is indeed the RO . 
 Thanks , now for the second part of my question . In we find : In this scenario , while no  is participating , so no Protected Resources are being accessed . We still have Should n't definition of RO should still be broadened from current Keeping in mind It might still be something in direction of subject entity that may grant or deny operations on resources or obtaining assertions containing attributes it has authority upon . In short , if RO plays role in . There seems to be more to that role than just granting or denying operations on resources ( an API served by RS ) . 
 My view is that the attribute part is covered by the fact that the RO is a subject ( obtaining them is covered by the subject definition now ) . The main rationale for the protocol is still related to access to protected resources , and I believe we would dilute that otherwise . 
 In that case is there any reason for to still include : I think 4 could be removed altogether and 5 could become ( after renumbering ) This section states in the first sentence that it does not involve RS and access to protected resources ( an API served by RS ) 
 We still need to make sure that the user is indeed the RO , hence step 4 . 
 I still consider that the information about the subject is counted among the " Resources " being released here . The only real difference is that instead of them being at an RS , they 're passed directly to the client instance . 
 Yes , this did n't change . I 'm only saying I do n't think it needs to be embedded into the RO definition , since we can assume from the subject definition itself that some mechanism exists to grab the subject attributes data if it consents to . Changing the RO definition or worse the ( protected ) resource definition makes the entire thing convoluted , at least in every variation I tried . 
 Right , and I think I agree with that . The definitions should try to stay tight , if we can . But if the surrounding text , especially the " subject information " request stuff is n't clear , then this is going to come around again . I do n't have a specific answer but I would be surprised if we ca n't improve this , since it 's come up a few times . 
 I am supportive of elf - pavlik when he writes : fimbault agrees with him when he says : When looking at Section 3.4 that is indicated in that section , the following text may be found . If information about the RO is requested and the AS grants the client instance access to that data , the AS returns the approved information in the " subject " response field . The case where information is about the end - user is not addressed , i.e. there is no sentence starting with : If information about the end - user is requested ( ... ) Does this mean that an end - user is not allowed to know which personal data is known by the AS about him ? If this would be the case , such a limitation would not comply with generally agreed privacy principles . The text is still not fixed in draft-08 . What are the benefits for a client to know information about the RO ? This may be crystal clear for the editor(s ) , but it is unclear for a lambda reader . 
 Based on recent conversations , especially it seems to me that the intention is to consider the subject as RO with regards to the information about them . I think this shows up clearly in since it does not involve any Protected Resources but it stills call the user RO . It might be helpful to document scenarios where there is more than one AS involved . Let 's say we have Alice using a client to access resources owned by  . Here we could have two different AS : AS providing user information about Alice to the client - here  would act as both End - user and RO and  not be involved at all AS providing access_token to the client allowing access for protected resources - here  would act as End - user and  as RO Does that scenario with two different   sound reasonable ? 
 Those two both make sense , and it makes sense even for them to be together . You could have those be the same AS as well , if  's resource server is protected by the same server  is using to log in to the client . But they 're different kinds of access , and it would make sense to talk about them in a single example scenario to help call out that difference . There 's also a weird case from the CIBA work in the OIDF :  uses client software to find out who  is . The canonical example given here is a call center :  needs to verify that the person calling her is actually  , and so  starts something with the AS that reaches out to  to approve the release of identity information about  to  , in real time . 
 how does  know which AS can release identity information about  ? I would not make an assumption that one global central AS exists and it has information about the whole Earth 's population ? 
 This use case is not assuming a global AS at all ( I agree , that 's absurd ) , but it is assuming that  and  are both working with a known ecosystem . In the case of the call center example , it 's the supporting company 's AS -- where  works and where  is a customer . So ,  needs to have an account there , and so does  .  's account needs to be authorized to get info about other users ( because she 's a support tech ) .  's account is a customer account that  can fetch information from anyway . 
 I see , thank you . It indeed looks like another use case where  acts as RO but there is no RS or Protected Resource involved . 
 I 've encountered the CIBA use case very recently . Here 's a summarised description : the enduser gets in touch ( out of band ) with the support , so that both are available at the same time the support needs to get read access to some info stored on the enduser 's mobile , and uses CIBA to get the enduser 's approval returned scopes define what can be accessed through another OIDC client ( used by the support agent ) there are no RS involved Note : this issue is closed , so either we should reopen it or open a new issue 
 Agreed , we 've drifted off of the topic of the issue as well . I opened up a new issue for discussion of the cross - user CIBA use case specifically :
Paragraph (version A):
person, organization or device.
Paragraph (version B):
person, organization or device.  It decides whether and under
which conditions its attributes can be disclosed to other parties.