jiebi/CodeConvo huggingface dataset:
Code change:
shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF RFC5869. </del> <ins> the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above.  Whilst SS and ES may be the same in some cases, the extracted xSS and xES will not. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.

Related discussion:
text: I don't have a better name right now, so close this if none better can be found. Also s/resumption master secret/resumption secret/ throughout, it's a little inconsistent.
Now master of more
Code change:
default of 53).  DNS URIs normally omit the authority, or specify an IP address, but a hostname and non-default port number are allowed. <del> When a non-default port number is part of a service identifier, Port- </del> <ins> When the binding authority specifies a non-default port number, Port- </ins> Prefix Naming places the port number in an additional a prefix on the <del> name.  For example, SVCB records for a DNS service identified as ""dns1.example.com:9953"" would be located at </del> <ins> name.  For example, if the binding authority is ""dns1.example.com:9953"", the client would query for SVCB records at </ins> ""_9953._dns.dns1.example.com"".  If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative

Related discussion:
text: This should help with the case in DDR. See URL
Much better. Thanks for indulging me.
Code change:
The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. <del> 7.7. </del> <ins> 7.8. </ins> Including a "Date" field in requests reveals some information about the client clock.  This might be used to fingerprint clients UWT or

Related discussion:
text: NAME noted that it was important to note that the Gateway needs to be trusted if gateway != target. As a practical matter, that means that you probably want gateway == target.
Hi, Since the gateways are seeing request/response pairs, there is a potential here for a side-channel attack at the gateway itself or at a relay. (if I understood the draft correctly - if not, please clarify my misunderstanding here). Are there mitigations planned for this type of issue that you could expand on in the Security Considerations section perhaps?
Does the new text in address this concern?
I don't think so, because the claim is the gateway does not have intimate knowledge of the contents of the request/response. If that assertion is true, the gateway shouldn't be able to ascertain information about the actual contents from those pairs (directly or indirectly, via a side-channel attack). If the burden is on the application developer to ensure that request/response pairs traversing the gateway are to be resilient to side-channel attacks of those pairings, then it would be good to explicitly call that out in this spec (perhaps in the security considerations section?) Thoughts?
NAME the gateway necessarily sees all request and response pairs, and will therefore always learn information about each transaction. This is fundamental to the design. Whether or not the gateway uses that information for malicious purposes, e.g., by providing different responses to different requests for the same target resource, depends on the trust model. And the change in addresses that. I don't think further text is needed here.
"Finally, a relay can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an Encapsulated Response." I feel that a relay could certainly perform a side-channel attack here as well using R/R pairings.
Can you please be more specific here? What type of attack could the relay do to violate client privacy that is not already documented in the draft?
Typically in HTTPs scenarios, it is more difficult to perform side channel attacks as a flow observer, especially if multiplexing of requests and responses are performed.
Code change:
The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. <del> 7.7. </del> <ins> 7.8. </ins> Including a "Date" field in requests reveals some information about the client clock.  This might be used to fingerprint clients UWT or

Related discussion:
text: In this design, if I understand it correctly, the requests and responses are being broken out into distinct exchanges that the relay can see and therefore it makes it easier for a relay to perform these types of attacks that would be more difficult had the relay not been used in the first place. If my understanding of the protocol is incorrect here, please feel free to point that out.
You seem to be describing fingerprinting attacks, wherein the observer uses features extracted from otherwise encrypted traffic to try and learn information about the underlying (unencrypted) data. Yes, the relay does have a more fine-grained view of each exchange compared to a network observer in this protocol since it can see explicit message boundaries, and that might impact the efficacy of these attacks. This is partly already addressed in the document: We could extend this to note the relay's view of message boundaries. I don't think any additional text is needed for the gateway.
Whatever you feel is best. I think some language around the message level risks this creates vs non-relay scenarios might be helpful. Does the client intentionally break things up in a way that crosses the underlying application message boundaries (e.g. more like packetization) with a relay? I have more questions about the gateway functionality that we can discuss separately.
This means that the client really needs to trust that the gateway doesn't muck with it. As a practical matter, this incentivizes clients to choose a gateway that is effectively the same entity as the target. They don't have to, but the amount of trust required of the gateway is higher if gateway and target aren't operated by the same entity. We touch on this, but we could be clearer about it.
Code change:
ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.

Related discussion:
text: Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 0d7a49a6be4a9740f850d2477b1f2462de781b10 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 don't have RS involved, so we also don'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 don'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?
Code change:
ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.

Related discussion:
text: Again in 2.2 we also don'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 doesn't grant or deny operations on resources (served by RS) but only grants / denies obtaining an assertion.
I agree that the specific language that NAME references should be tightened up. What's a little awkward right now is that GNAP's language treats access to an RS and access to information contained in assertions as protected resources, but it doesn'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 RS (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 doesn'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.
Code change:
ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.

Related discussion:
text: 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 GNAP so I don't mean to overstate it.
NAME 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?
NAME I really don'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 don'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.
Code change:
ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.

Related discussion:
text: -- URL (the AS) and running at https://ognap-URL -- URL and running at https://ognap-rs-URL -- URL The protected resource is going to be_ just a self-verifying vaccine credential (I invented) -- URL -- Some of this is running at URL 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 URL 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 NAME and NAME : 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 don'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?
Code change:
ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.

Related discussion:
text: 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 NAME and NAME I've tried some sentences to specify subtypes for resources, but it becomes very confusing. The proposal by NAME 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 NAME 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 wouldn'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 added 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 NAME 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.
Code change:
ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.

Related discussion:
text: If that's the case what would be the case where the subject decides to disclose some attributes but doesn't act as RO?
I'm not entirely sure about the use case you're targeting here. Could you be more specific ?
Maybe I shouldn'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 don'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 RS is participating, so no Protected Resources are being accessed. We still have Shouldn'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 didn't change. I'm only saying I don'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.
Code change:
ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.

Related discussion:
text: Changing the RO definition or worse the (protected) resource definition makes the entire thing convoluted, at least in every variation I tried.
NAME 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 isn't clear, then this is going to come around again. I don't have a specific answer but I would be surprised if we can'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 URL 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 Bob. Here we could have two different AS: AS providing user information about Alice to the client - here Alice would act as both End-user and RO and Bob not be involved at all AS providing access_token to the client allowing access for protected resources - here Alice would act as End-user and Bob as RO Does that scenario with two different Authorization Servers sound reasonable?
NAME Those two both make sense, and it makes sense even for them to be together.