Reliable Data Source

[Scott Rea]

G’day Corey,

Maybe a topic for a subsequent Validation meeting:

As we evaluate candidates for data sources to be termed a “Reliable Data Source” under the TLS BRs, there are some guidelines in 3.2.2.7 to evaluate data source accuracy, but no real calibration of the elements that should be considered to determine what level is more desirable and what is less desirable, and why. Maybe some folks have historical context they might be able to share around the list of considerations listed and motivations for including them. Anyway, I would love a brief discussion on these and any insights folks might have - or is there some body of guidelines that I am completely missing, that already covers this in this regard?

To give an idea of what I mean, CAs should consider "The public accessibility of the data availability,” as one consideration. Does this mean that an RDS that is potentially a pay_for_service is not desirable because it's not publicly available (unless you pay the fee)? How does this make it any less reliable?

Interested in a short discussion on this topic at an upcoming meeting.

Regards,

_Scott

Disclaimer: The email and its contents hold confidential information and are intended for the person or entity to which it is addressed. If you are not the intended recipient, please note that any distribution or copying of this email is strictly prohibited as per Company Policy, you are requested to notify the sender and delete the email and associated attachments with it from your system.

[Inigo Barreira]

Along with this, it could be of interest the “trusted authentic sources” that is taking place as per eIDAS2 and ETSI is developing, meaning that these sources will be the real owners of the data and those you can rely on. The context is a bit different because it´s for attributes attestation but it can be potentially used for other matters.

 

De: 'Scott Rea' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org>
Enviado el: jueves, 22 de enero de 2026 9:58
Para: Corey Bonnell <corey....@digicert.com>
CC: CABF Validation WG <valid...@groups.cabforum.org>
Asunto: [cabf_validation] Reliable Data Source

 

G’day Corey, Maybe a topic for a subsequent Validation meeting: As we evaluate candidates for data sources to be termed a “Reliable Data Source” under the TLS BRs, there are some guidelines in 3. 2. 2. 7 to evaluate data source accuracy, but no

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender This message came from outside your organization.     Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/KL1PR0401MB501706FA4A530DBD4BCBE525F097A%40KL1PR0401MB5017.apcprd04.prod.outlook.com.

[Scott Rea]

Yeah, I think those are things that are definitely part of the scope of considerations - thanks for pointing those out.

As we move into an era of verifiable credentials, these might also be considered an RDS if sufficient rigor is behind the authority signing those, and how do we assess that level of rigor? Not just for the source, but for the infrastructure signing the assertions?

Some things to think through perhaps …

Regards,

-Scott

On Jan 22, 2026, at 2:11 PM, 'Inigo Barreira' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org> wrote:



To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/DM4PR17MB6293D5E9FE17E4AEE75B341D8197A%40DM4PR17MB6293.namprd17.prod.outlook.com.

[Inigo Barreira]

For example, the current definition of authentic source is:

 

authentic source: repository or system, held under the responsibility of a public sector body or private entity, that contains and provides attributes about a natural or legal person and is considered to be a primary source of that information or recognised as authentic in accordance with Union or national law, including administrative practice NOTE 1: As per eIDAS definition

NOTE 2: This include any source irrespective of its form that can be relied upon to provide accurate data, information and/or evidence that can be used to provide attributes about a natural or legal person.

 

This is similar to our QGIS/QIIS/etc. sources but that are somehow listed as authentic.

 

And even though this is mostly related to the EUDI wallet and attestation of attributes also provides information of the natural or legal person.

 

As per the STF 705, there are some upcoming standards that could be also of interest.

The EN 319 478 will be about specification of interfaces related to authentic sources.

The EN 319 482-5 will be about specification of systems enabling the notification and subsequent publication of provider information.

 

Regards

 

De: Scott Rea <sc...@scottrea.com>
Enviado el: jueves, 22 de enero de 2026 12:17
Para: valid...@groups.cabforum.org
CC: Corey Bonnell <Corey....@digicert.com>
Asunto: Re: [cabf_validation] RE: Reliable Data Source

 

Yeah, I think those are things that are definitely part of the scope of considerations - thanks for pointing those out. As we move into an era of verifiable credentials, these might also be considered an RDS if sufficient rigor is behind the

ZjQcmQRYFpfptBannerStart

This Message Is From an Untrusted Sender You have not previously corresponded with this sender.     Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/1B8367C0-3CAF-4167-8E10-3DAA5EFD2C8E%40scottrea.com.

[Scott Rea]

Thanks Inigio - this is very helpful!

One thing I want to explore, is the possibility of using a Qualified Electronic Seal as a source of authentication. But the challenge I see is the following: 

1. The current definition of RDS says it can be “...an identification document or source of data used to verify Subject Identity that is generally recognized among commercial enterprises and governments as reliable” which potentially a QES could/should provide, but
2. The second half of the RDS definition in the BRs is problematic for QES because it says “...was created by a third party for a purpose other than the Applicant obtaining a Certificate” and clearly a QES was created for the purpose of obtaining a certificate...

Thoughts?

Regards,

_Scott

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CY8PR17MB62832EB3598EA3A47E445A058194A%40CY8PR17MB6283.namprd17.prod.outlook.com.

[Inigo Barreira]

Well, I think the definition on RDS is a bit generic in terms of where to get information to issue a certificate, but in eIDAS article 24, item 1, is indicated that you can order a certificate by using other certificate, because that first one has been issued to a person that has been clearly identified.

 

So, it´s like for the first certificate issuance you have used a RDS (for example the passport which has been used to identify you) and once obtained you can order another certificate because you have been already identified and therefore no need to go thru another identification process.

 

Regards

 

De: 'Scott Rea' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org>
Enviado el: viernes, 23 de enero de 2026 12:36
Para: 'Inigo Barreira' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org>
CC: Corey Bonnell <Corey....@digicert.com>
Asunto: Re: RE: [cabf_validation] RE: Reliable Data Source

 

Thanks Inigio - this is very helpful! One thing I want to explore, is the possibility of using a Qualified Electronic Seal as a source of authentication. But the challenge I see is the following: The current definition of RDS says it can be

ZjQcmQRYFpfptBannerStart

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/TYZPR04MB5010F7EB274FCDCC70FD876BF094A%40TYZPR04MB5010.apcprd04.prod.outlook.com.