Trust marks / Links

[Tom Jones]

1. As Roland points out - with zero trust it MUST be possible to validate trust mark/links at any time.
2. The trust mark and the link to the authorities should be one and the same thing - ie there is no need for the mark, all it is is a link to the authority. (That implies that there MUST NOT be two authorities per mark. If the user asks someone else for assurance, that other party becomes the trust authority and the RP needs to be able to explain that in a security audit.)
3. Some people think that the trust mark is static, that it just points to the authority, but that seems to be pointless. if it points to the authority, it should contain the entity id in the link. That makes this point a request for a change to clarify that.
4. If 3 is true, then it answers 1 and the trust mark is recognized as the best possible answer to point one.

In this issue RP means the party relying on the trust.

[Giuseppe De Marco]

good points,

1) ideally it should this way in all the cases

on 2) we wonder about unique IDs with url, like "id": "https://www.spid.gov.it/certification/rp"
but there can possibilities to have some kind of shared marks, for example between agencies, countries, etc.

let’s assume the adherence on a security framework, self issued by an organization. It’s not the owner of the framework but it can issue marks on that to all of its descendants. These wouls be special cases, we know and the final result strictly depends about the trust that a verifier have with the issuer.

`````
{
  "iss": "https://www.agid.gov.it",
  "sub": "https://rp.example.it/spid",
  "iat": 1579621160,
  "id": "https://www.spid.gov.it/certification/rp",
  "mark": "https://www.agid.gov.it/themes/custom/agid/logo.svg",
  "ref": "https://docs.italia.it/italia/spid/spid-regole-tecniche-oidc/it/stabile/index.html"
}
`````

3) I agree, anyway a research and scholarship organization could issue a code of conduct trust marks with a unique and shared id between many R&S, orgs and countries

4) I agree, anyway the verifier applies the policy and it knows who’s the issuers it trusts or not

[Tom Jones]

The idea (AFIK) of federation is that there is a single root of trust. Somehow SSI/DIF folk seems to think that unnecessary.

The existing implementation of federation in the R&E community (Internet 3?) is that federation can go from the trust authority to the university (possibly then to labs) and then to the entity.

If you want some sort of governance w/o a single root of trust, I suspect you need to work with ToIP and create the governance, otherwise there is no way for a end entity to determine trust that i know of. This is a HARD PROBLEM. A problem that i do not believe is ready for standardization.

(BTW I am working on that problem with COVID credentials - is that where you think the issue is being articulated?)

‌

[David W Chadwick]

Tom there are other use cases that I am aware of

i) A trust federation in Asia is deemed by a European federation operator (root of trust) to be equivalent to its trust federation in Europe, so a VC issued by an Asian issuer who is a member of the Asian federation, can be trusted by an RP in the European federation. The RP would like the European authority to evaluate this for it.

ii) The authority that evaluates federation membership acts on behalf of several federations and therefore has a common entry point for multiple federations.

Both of these indicate that it is not always the case that the authority who is trusted to evaluate federation membership is the federation authority itself.

In the world of PKI we have the concept of indirect CRL. So conceptually it is similar to this.

[Tom Jones]

CLRs are dead - let’s leave then out of the conversation.

How is a RP to understand all that hand waving in your posting?

Given the state-of-the-art we still need a place for the RP to go for a root of trust.

‌

[David W Chadwick]

The RP is in fact the root of trust. It decides everything, including which entities to delegate trust to. So in short, the RP may decide to join a federation, and may decide to trust the federation authority, and may decide to use the federation’s service to evaluate the trustworthiness of the VCs that it has received from previously unknown issuers

[Tom Jones]

you are confusing perfectly good existing taxonomy.

The RP and/or the Access point is the root of all authorization.

The RP starts (in Zero Trust) with no trust assumptions and acquires them till satisfied.

Calling the RP the root of trust really will confuse everyone.

‌

[David W Chadwick]

“with no trust assumptions” except one - it trusts itself

[Tom Jones]

That is actually a pretty rash statement and it is only true at the point where a software and device audit completes successfully.

I certainly have very limited trust of the code that goes out onto the web on my behalf. And that is who i am on the web.

It would be more accurate to say:

1. I am my own trust authority
2. I have a list of trust authorities I will accept (on the browser that list is maintained by your browser mfg.)

‌

[David W Chadwick]

1. Is a restatement of the RP being its own root of trust
2. Is a restatement of the RP delegating trust to other trust authorities

So we appear to be in complete agreement, but using different phraseology.

‌

[Roland Hedberg]

A trust mark as it is defined in the document right now is a set of metadata.

One attribute in the metadata points to the issuer of the trust mark another attribute is an identifier. To have an unique identifier of a trust mark allows you to have more the one issuer of trust marks with the same id.

Note that trust marks might not be directly connected to the federation. As an example in the document we have the self asserted trust mark that is connected to the OIDC test suite.

The fact that we, as it is specified in the document, allows more than one issuer of a special type of trust mark leads to the conclusion that the trust mark and the link to the authorities can not be one and the same.

Now, when it comes to the trust mark that represents an entity’s participation in a federation IMO this can only come from one authority and that is the Trust anchor.

[Roland Hedberg]

I totally agree with the notion that trust marks are dynamic and that one most be able to verify that they are active.

[Tom Jones]

1. I find those last to statement to be incompatible.
2. I strongly object to the first “The document, allows more than one issuer of a special type of trust mark leads to the conclusion that the trust mark and the link to the authorities can not be one and the same.” And I believe it should be changed.

‌

[Giuseppe De Marco]

1. Let’s assume I have my graduation certificate hanging in my home office. That at the same time the university that issued it later revoked it. The certificate is still hanging in my study, but it’s no longer valid. Whoever checks if I’m a graduate will not look at my certificate in the study but at the papers issued by the university that issued that certificate.
2. two entities create a memorandum of understanding and decide to mark all the services created with this memorandum of understanding, each owner of the service brand their own using the trust mark and both can issue it. Another example, adhesion to security frameworks according to self-certification methods. The Issuers of the same trust mark are different in these cases.

‌

[Tom Jones]

I don’t think that the last comment had anything to do with my request. So, to be clear here is my point.

For a given trust mark on a given web site (origin, whatever) there is one and only one place to go to validate the currency of the trust mark.

It could certainly be that the trust anchor just returns a current entity statement, that is one way to deal with the issue.

As a separate issue the relationship of the trust mark to the sites that can display it is similar to the problem with an X.509 ssl cert. Perhaps that point needs to be addressed as well. At a minimum the issue of same origin needs to be addressed in the document so that the trust mark can be used on any endpoint that meets the browser same origin policy and no other.

[Tom Jones]

BTW - allowing different trust anchors is a security risk, that perhaps needs to be in the security section. If anyone can use a trust mark and apply their own trust anchor, then the trust mark is operationally insecure as anyone can use it with no limitation. There may be legal limitations, but attackers are not limited by laws in the current web ecosystem.

[David W Chadwick]

I support a trust mark only having one authoritative issuer. But verification of the trust mark should be delegate-able by the RP to an authority that it trusts to do this on its behalf. Usually this will be to the authoritative issue, but it should not be mandatory. Similarly the issuer could delegate validation to TTPs that it has relationships with, and it should be able to publish this. So I think we should separate the concepts of the issuing authority and the verification authority. In the simple case they will be the same, but in more complex eco-systems they will be different.

[Giuseppe De Marco]

The issues you exposed rely on the trust that a party places to the trust mark, in a multilater federation we may have many kind of trust marks, it’s up to the verifiers assign a meaning on the trust marks before resolving them.

If the RP doesn’t recognize the meaning and the nature of a trust mark this means that trust mark is useless to be considered by the RP, and it won’t be checked by the RP. All this to say that we may configure trust marks in the specs without restricting them to which scope and security awareness they bear, all the security aspects of their meaning and usage in a federation is up to federation authorities and to verifiers.

In the use case I'm working on we don't admit, at this moment, that a single trust mark could be issued by multiple issuers. In my context we have two federations with two different trust anchors, each one is the unique issuer of its trust marks.

However, in the future, it may be conceivable that both federation authorities will join a single security framework that makes them capable of issuing the same trust mark autonomously. It’s just an option, I think the specifications of the standard should not place categorical restrictions on these use cases

[Tom Jones]

Sounds like a plan. I would like to point out that when two federations get together, but still maintain their identity for posterity, that the typical way is to create yet another root of trust they they both belong to. Then each of their enmity statements would be changed to point to the high level root.

[Giuseppe De Marco]

It's what I'd do for sure

We have to admit that this issue Is related to policy and governance aspects that's up to Fed authorities and members.

These could be some good best practices

[Michael Jones]

Is there a specific proposed spec text change that is being proposed to capture the conclusions of this discussion?

[Tom Jones]

@Roland - what section does this quote from you:

The fact that we, as it is specified in the document, allows more than one issuer of a special type of trust mark leads to the conclusion that the trust mark and the link to the authorities can not be one and the same.

[Roland Hedberg]

1. Trust marks may describe things about an entity that has nothing to do with the entity being part of a federation. Issuers of trust mark can therefor be any entity in a federation.
2. Trust marks in the specification are described by a JSON object containing among other the attributes “iss” (= issuer) and “id” (unique identifier of the type of trust mark). There is no text in the document that says that there can only be one issuer of a special type of trust marks hence there can be more then one issuer of trust marks with a specific “id”.
3. Trust marks are in no way specific to a federation. There may be trust marks that are like the one proposed for handling “immediate” removal of an entity from the federation but that is an except rather than the rule. This type of trust marks are likely to be the only trust marks that the trust anchor issues.
4. As Guiseppe says if an entity receives a trust mark it doesn’t understand it should just ignore it.

‌

[Tom Jones]

based on Roland’s description i do not believe that the Federation Document can be used in Health care - this was discussed by several of us that work in that field. I suggest that the entire idea of trust mark should be removed or you will find that many communities will reject the spec. If we need an entity statement in health care we will likely just recreate it so that we don’t need to reference a spec with these definitions.

OTOH the project that used the entity statement in HealthCare has been on hiatus for about 6 months, so you may decide that you don’t care.

Use of the trustmark as defined here in self-issued ID also seems to be wrong. Here is a description about how that might work https://wiki.idesg.org/wiki/index.php/Trustmark_Evolving_Design_Pattern

[Michael Jones]

What is the IDESG definition and what’s the conflict you see with the OpenID Connect Federation definition?  Do you have a suggestion on how to resolve the conflicts?

(I looked at the wiki page referenced and didn’t see a definition or a Terminology section.)

[Roland Hedberg]

So maybe Trust Mark as defined in the context of the specification should be named something else since the meaning is not the same as IDESG trust Marks. IDESG trust Marks has a much more narrow definition than what we are trying to capture by OIDCfed Trust Marks.

AS an example we could haveIDESG Trust Marks and Trust Statements side by side. Where Trust Statements is what we now call Trust Marks.

I’m in no way wedded with the name Trust Marks. If we are infringing on someone else's definition I’m happy to find an alternative way.

[Roland Hedberg]

Hmm, a better name could be Compliance Statement because that is really what I (at least) where aiming for.

[Giuseppe De Marco]

Compliance Statement sounds good and has a good semantic.
By the other side trust marks is shorter but, anyway, we can abandon it.

trust_mark fits quite good as JWT claim, because is short!
using compliance statement, what would be the claim name?

[Roland Hedberg]

OIDC has an abundance of long claim names. So this would just fit right in.

If we wanted something shorter and choose something like c_stat

[Giuseppe De Marco]

compliance marks I think it’s easier to understand.
The concept of "mark" is extremely appropriate, I would propose c_mark

stat too easily leads to the meaning of statistics

[Michael Jones]

On the 27-Jan-22 working group call, we agreed not to change the name of “Trust Mark”.

[Tom Jones]

I will recommend removal of any reference to the OIDC fed spec.

FWIW, Microsoft Health is participating in the health care federation effort

[Michael Jones]

Tom, you’ve never given us a clear explanation of what the problem is that’s causing you to respond this way. In what way do you perceive the Trust Marks in OpenID Connect Federation as being in conflict with, rather than complementary to, other definitions of Trust Marks. And what are the specific other definitions of Trust Marks that you’re referring to?

[Tom Jones]

I thought about trying to answer Mike’s point as a issue, but that would not get anywhere near the problem. As I see it the problem is that whoever happens to be looking at the doc as it rolls towards standardization tries to get their use cases included in the standard, which is what i see about the use of Trust Mark in this spec. I would not recommend accepting as a normative standard one that used terms in a way that was inconsistent with the standard that referenced it. In my view, standards should be written to be used by as broad a population as possible. If there are different meanings, it is best to remove that from the standard. Otherwise there will be places where features, like the entity statement, are copied out of the spec, but the spec cannot be listed as normative. My vote would always be to make the standard as general as possible and not to try to include every use case that came along. So, lets just take the references to Trust Mark out of the spec altogether.

[Roland Hedberg]

It was decided at the 27-Jan-22 working group call that the text should stand as is.

[Giuseppe De Marco]

Hi @Tom Jones , I have been thinking about the value of trust marks like static JWT and signed by a trusted entity. I want to share it here with you. When an "automatic client registration" arrives, an OP, in my ideal/real world, must:

1. acquire or update the trust anchor entity configuration first, if one or more of them. It should already have it a priori.
   1.1 acquire the entity configuration of all the trust_marks_issuer published by the trust anchor
2. acquire the entity configuration of the requestor (.well-known/openid-federation)
3. search for a recognisable trust mark within the requestor entity configuration and, if true, validate it with the corresponding jwk of the trust anchor or any of its trust_mark_issuers, retrieved at point 1

If 3 fails, no metadata discovery will occur.
No joker would create his own .well-known/openid-federation with dozens of authority_hints inside it, to cause entropy within the federation.

In this scenario the trust mark is also a filter. Those who have trust marks issued by well-known Issuers adhere to the federation and are worthy of metadata discovery!
this prevents any useless http request to third parties

This not prevents that in a signed trust mark can be configured a link to a third party resource, why not, it can

[Tom Jones]

so;unds ok - i guess i would add that the metadata discovery link should be attached to the trust mark so that the rp could verify that the mark was still current. And it’s fine if the link will not resolve later. that is a valid negative result

[Giuseppe De Marco]

Some of my fellow Members put this to me a few days ago and I remembered you!

There are 3 assumptions at the base:

1. The verification url of the trust mark would ideally be the "trust mark status" endpoint exposed in the entity configuration of its Issuer. As we know this endpoint is optional (because trust marks are optional).
2. The verification url of all valid trust marks and the final metadata is ideally "resolve entity statement", which is also exposed in the entity configuration of a trust anchor or any other participant we have trust, also optional.
3. We may include a url within the trust mark to implement verification mechanisms that exceed OIDC Fed specifications. It is possible and covered by specifications that do not prohibit any additional claims. I see trust marks as extensions of trust assessment mechanisms.

On step number 3, think about DID or SOLID OIDC WebIDs. We’re talking about this, we’re looking at pros and cons. One thing is certain, we must be careful not to "inflate" these blessed trust marks, otherwise we risk requiring the implementations to cover too many methodologies and all at once

[Roland Hedberg]

Regarding (1) my view is that a trust issuer that issues trust marks that can expire MUST implement a trust mark status endpoint.

[Michael Jones]

Are we ready to close this issue, given the decision on the 27-Jan-22 working group call to not to change the name of “Trust Mark”?

[Giuseppe De Marco]

ok

[Michael Jones]

The working group reconfirmed the 27-Jan-22 decision not to change the name of Trust Marks on the 21-Apr-22 working group call.