Metadata policy handling

[Roland Hedberg]

Hi guys,

It’s about time new nail this down. :-)

If we’re going to do policy testing in the next interop we must know how it is supposed to work.

There are 4 view points, an RP doing explicit or automatic registration and an OP supporting explicit or automatic client registration.

Let’s look at what happens/should happen in each case.

Explicit

----------

1) The RP sends a provider information discovery request to the OPs federation_registration_endpoint.

The response contains one or more authority_hits pointing to trust anchors. In the following text we

name them A, B and C.

2) The RP makes a decision as to which authority_hints it will include in the client registration request.

If it has A and B as trust anchors it can add authority_hints that leads to A, B or A and B.

3) The OP choses which trust anchor to be used as the bases for future communication. It signals this

choice by adding trust_anchor_id to a federation_entity section of the entity statement.

(according to one section in the specification trust_anchor_id is a claim in the RP's metadata, but in the description of

explicit registration it is part of the federation entity’s metadata. 

This reflects that there is no obvious place for it we just have to pick one.)

At this point the OP can calculate the metadata policy that MUST be applied to the RP's metadata

in order to make it comply to the wishes/policy of the OP as well as the federation. This gets reflected to the RP

through the registration response (which contains metadata_policy and trust_anchor_id).

The OP can also calculate what its metadata is within the boundaries of the federation. It would do well to 

store it or a reference to it in the information it keep about the client. Such that it can easily know how to act when

talking to that specific client. But that’s just an implementation issue.

4) Back at the RP it has now received the response from the OP and can calculate its metadata.

It does that by adding the metadata_policy returned from the OP to the list of metadata_policies that

exists in the trust chain that ends in the trust anchor that has the id trust_anchor_id. And then applying the

combined metadata_policy to the metadata included in the registation request.

Automatic 

——————

1) is the same as explicit(1)

2) The RP could do something similar to explicit(2). If it supported multiple entity_ids it could have 

entity statements with different authority_hints sets in each of them. And then chose one of the entity_ids when sending the

authorization request.

3) The OP choses which trust anchor/federation to use and as I wrote in a comment on Slack it should

signal this by adding trust_anchor_id to the authorization response.

The OP can now calculate its own metadata and it can also calculate the RP's metadata within that federation.

But it can not influence in any way what the RP’s metadata will look like.

4) Back at the RP, the RP can calculate what its metadata as well as what the OP’s metadata will look like in the chosen federation.

Since its own metadata doesn’t change depending on which OP it talks (assuming it doesn’t chose the multiple entity_id trick) to it can precalculate this for all federations it belongs to.

General comment

————————————

It’s always true that the OP can chose to have its metadata only be dependent on which federation it

partakes in and in no way be influenced by the RP's metadata. If it choses to do so it can precalculate its metadata for

all federations it belongs to.

Comments !!

— Roland

There is nothing you cannot prove if your outlook is only sufficiently limited. (Dorothy L. Sayers, ”Whose body?”)

[Vladimir Dzhuvinov]

Hi Roland,

Could you tell us if the existing SAML federations have something similar and what their practical experience has been?

Vladimir

--
You received this message because you are subscribed to the Google Groups "openid-federation-interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openid-federation-...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/85980DED-2346-4847-BAA8-16048C246657%40catalogix.se.

-- 
Vladimir Dzhuvinov

[Roland Hedberg]

Simply put, no there is nothing similar in the SAML federations.

Each entity in a SAML federation is represented by one metadata set.

And that set is independent on who it may talk to within the federation.

This also means that having one entity belonging to more then one federation can only happen if

the metadata basically stays the same.

And finally an entity in a SAML federation registers with the federation and all the information flows from

the federation to the federation entities. 

There is nothing like the provider info discovery or client registration in SAML federations.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/aa25be3c-a199-d675-1e08-5bd1ede78f10%40connect2id.com.