jiebi/CodeConvo huggingface dataset:
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.
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.
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.
You could have those be the same AS as well, if Bob's resource server is protected by the same server Alice 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: Alice uses client software to find out who Bob is. The canonical example given here is a call center: Alice needs to verify that the person calling her is actually Bob, and so Alice starts something with the AS that reaches out to Bob to approve the release of identity information about Bob to Alice, in real time.
NAME how does Alice know which AS can release identity information about Bob? I would not make an assumption that one global central AS exists and it has information about the whole Earth's population?
NAME This use case is not assuming a global AS at all (I agree, that's absurd), but it is assuming that Alice and Bob are both working with a known ecosystem. In the case of the call center example, it's the supporting company's AS -- where Alice works and where Bob is a customer. So, Bob needs to have an account there, and so does Alice. Alice's account needs to be authorized to get info about other users (because she's a support tech). Bob's account is a customer account that Alice can fetch information from anyway.
I see, thank you. It indeed looks like another use case where Bob 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
NAME 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:
Based on URL I suggest using Reference Values to keep consistent with the RATS arch.
+1 for "Reference Values"
on it Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft. DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections. Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me.
Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have? 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier.
Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment? Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well.
From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation. Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments.
This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section. Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan
N was introduced in to describe how a sender might pace at a rate that allows it to send a congestion window's worth of data in a period that is shorter than an RTT. This PR clarifies text that goes into unnecessary detail, trying to describe assumptions (the network is spreading the packets out, for example, resulting in an ack clock).
Can we make progress in this one?
Yes, I'm waiting for the design issues to get done before moving on the remaining editorial ones.
I think that has happened now :-)
Nudge
NAME does this look better?
LGTM, though I'd change the attacker from a "he" to a "they" on general principles.
Not a huge fan of the singular "they", but can't be bothered to rewrite around it :)
Yes, this is clearer. Thanks. Saying "will cause the server to query an arbitrary URI" is good. Technically you can even specify a non-HTTP protocol in an HTTP redirect, and this language should cover that too. (Go's net/http used by Boulder only does HTTP and HTTPS I think, but things like libcurl support a slightly insane number of protocols.) I'm not sure if the usages of "URI" vs "URL" in this section are correct, you may want to make them consistent. I never know which one to actually use. This looks good to me.
URL Greetings! I got as far as I could with time constraints through the rest of the document. There are a few sections I'll likely go back over again as I was short on time when reviewing them, but do hope this is helpful towards improving the document. This review is from the editors revision on github that I started my review earlier int he week. Section 4.2: I find the following grouping a bit confusing: "Places that Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware." This has an attesting environment as a processor, an element, and as compiled code. That doesn't seem right, especially when you refer to the attesting environment as a "place". Do you mean where BIOS is executed perhaps? I would expect a TEE and maybe other components where security functions are offloaded, which is in some cases to a processor other than a TEE like a GPU (I'm not making a recommendation to do that here, just stating what is happening in ecosystems that exist). The following text is a little confusing, in particular, the last sentence: "An execution environment may not, by default, be capable of claims collection for a given Target Environment. Attesting Environments are designed specifically with claims collection in mind." If the attesting environment is a place, TEEs and other processors were not necessarily designed with claims in mind. If you can help to explain an attesting environment better, I can help to phrase it more clearly to convey the intended set of points as I think there are several. Section 4.3 Consider changing from: "By definition, the Attester role takes on the duty to create Evidence." To: "By definition, the Attester role creates Evidence." The following sentence is a run on and I think some additional information will help provide clarity. I don't think it's the role that is composed of nest environments. Current: "The fact that an Attester role is composed of environments that can be nested or staged adds complexity to the architectural layout of how an Attester can be composed and therefore has to conduct the Claims collection in order to create believable attestation Evidence." How about: "An Attester may be one or more nested or staged environments, adding complexity to the architectural structure.