You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I forward a question here that I hear many times, which I think we should examine one more time before this standard is published.
The problem here is that OpenID federation includes tools to alter the metadata of an entity:
An Intermediate can set metadata values directly using the metadata claim
An Intermediate or Trust Anchor can define a policy using 'value', 'add' or 'default' that changes the leaf entity metadata.
The question I get then is if a leaf entity has to resolve its own metadata before talking to a peer in order to make sure that they honor their own metadata settings as viewed by that peer. One problem here is that they may not know which Trust Anchor or what path the peer is using.
This is all theoretical, but it may become practical and I would say that it is definitely an implementation concern. How do you make sure you act in accordance with the metadata the peer can see about you.
I personally think this is a mistake that I would prefer to see corrected. I would prefer if the chain can restrict or invalidate, but not alter or add to metadata declared by the leaf entity. If metadata must be added or altered, then It's better to fix the metadata and capabilities of the leaf entity in its Entity Configuration, than it is to alter it during chain validation. I believe the optimal changes would be:
Only provide metadata claim in Entity Configuration statements
Remove the 'value', 'add' and 'default' policy operators.
I also understand that such changes late in the process is never popular, and I don't expect any changes. But a discussion, and perhaps some guidance could be useful in the document to highlight the issue and dangers with altering metadata.
I would appreciate your thoughts on this.
The text was updated successfully, but these errors were encountered:
@peppelinux The big question is if that is a manual check, or an automated process. Automation is a really big challenge since you have to implement logic for a wide range of parameter and their implications. If the goal is to reduce complexity, this may be a substantial problem. Is the advantage really worth the negative effects here? What are the motivating use-cases?
Isn't the same effect achieved by a policy that blocks the entity if certain values are not set. This will cause that entity naturally to fix their metadata. Or?
I forward a question here that I hear many times, which I think we should examine one more time before this standard is published.
The problem here is that OpenID federation includes tools to alter the metadata of an entity:
The question I get then is if a leaf entity has to resolve its own metadata before talking to a peer in order to make sure that they honor their own metadata settings as viewed by that peer. One problem here is that they may not know which Trust Anchor or what path the peer is using.
This is all theoretical, but it may become practical and I would say that it is definitely an implementation concern. How do you make sure you act in accordance with the metadata the peer can see about you.
I personally think this is a mistake that I would prefer to see corrected. I would prefer if the chain can restrict or invalidate, but not alter or add to metadata declared by the leaf entity. If metadata must be added or altered, then It's better to fix the metadata and capabilities of the leaf entity in its Entity Configuration, than it is to alter it during chain validation. I believe the optimal changes would be:
I also understand that such changes late in the process is never popular, and I don't expect any changes. But a discussion, and perhaps some guidance could be useful in the document to highlight the issue and dangers with altering metadata.
I would appreciate your thoughts on this.
The text was updated successfully, but these errors were encountered: