Skip to content
This repository has been archived by the owner on Jun 14, 2022. It is now read-only.

Commit

Permalink
Merge pull request #29 from alanbuxey/patch-7
Browse files Browse the repository at this point in the history 
trivial section 8 fixes
  • Loading branch information
@rohe
rohe authored Oct 16, 2018
2 parents d0829b0 + 53358e1 commit 1ca9cac
Showing 1 changed file with 34 additions and 35 deletions.
69 changes: 34 additions & 35 deletions draft/oidcfed.hf.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -729,8 +729,9 @@ Content-Type: application/json
<section anchor="trust_lifetime"
title="Calculating the lifetime of a trust chain">
<t>Each entity statement in a trust chain is signed and MUST have a
expiration time (exp) set. The earliest expiry time defines the
expiration time of the whole trust chain</t>
expiration time (exp) set. Given that all of them are sometime in the
future then the expiration time of the whole trust chain is then the
expiration time that is closest in time to the present time.</t>
</section>
</section>

Expand All @@ -751,20 +752,20 @@ Content-Type: application/json

<section title="Leaf node key-rollover on keys used in protocol">
<t>A leaf node, such as an OpenID Provider will typically have at
least two sets of key pairs, one that is embedded in the entity
least two set of key pairs, one that is embedded in the entity
statement issued by the superior trust issuer, and one that is
embedded in the protocol specific metadata that is included in the
self-issuer entity statement.</t>
self issuer entity statement.</t>

<t><list style="numbers">
<t>Generate a new key pair to use K2 to replace the existing K1.
The lifetime T1 is the time until all previously issued entity
statements are expired.</t>

<t>Publish both K1 and K2 in the self-issued entity statement. Use
<t>Publish both K1 and K2 in the self issued entity statement. Use
K1 to sign outgoing messages. Accept encrypted messages to both K1
and K2. Set K2 to prioritized key. Wait at least T1 before moving
to the next step.</t>
to next step.</t>

<t>Remove K1 from published entity statements. Start signing
outgoing messages with K2, accept incoming encrypted messages with
Expand All @@ -776,15 +777,15 @@ Content-Type: application/json

<section title="Key-rollover for entity signing key">
<t>Identical to the section above, but the entity statements is issued
by the superior party, such that an out-of-band process for the entity
by the superior party, such that an out of band process for the entity
to push its key material to the superior entity MUST be added.</t>
</section>

<section title="Key rollover for trust roots">
<t>As previous steps.</t>

<t>Take into consideration that clients have manually configured
public keys as part of the configuration.</t>
<t>Take into considerations that clients have manually configured
pubic keys as part of configuration.</t>
</section>

<section title="Updating metadata">
Expand All @@ -798,7 +799,7 @@ Content-Type: application/json
</section>

<section anchor="flattening-metadata"
title="Flattening metadata from chain of entity statements">
title="Flattening metadata from the chain of entity statements">
<t>The metadata for a specific entity can be constructed by starting
with the information in ms_0 and then adding the information in ms_1 to
ms_n using the following rule:</t>
Expand All @@ -824,8 +825,8 @@ Content-Type: application/json
<t hangText="Integer/Floats"><vspace/> The number A is a subset of
the number B if A is less or equal to B.</t>

<t hangText="Associative array/dictionary"><vspace/> A dictionary A
is a subset of a dictionary B if every key in A is in B and the
<t hangText="Associative array/dictionary"><vspace/> The dictionary A
is a subset of the dictionary B if every key in A is in B and the
value of A[x] is a subset of B[x].</t>
</list></t>

Expand Down Expand Up @@ -878,15 +879,15 @@ Content-Type: application/json
</section>

<section title="OpenID Connect Communication">
<t>The section describes how the trust framework in this specification
<t>This section describes how the trust framework in this specification
is used to establish trust between an OpenID Relying Party and an OpenID
Provider that has no explicit configuration or registration in advance.
The use of OpenID Connect Federation enables dynamically building large
scale multi-lateral federations.</t>

<t>There is two alternative approaches to establish trust between a
<t>There are two alternative approaches to establish trust between a
Relying Party and a Provider. Members of a federation or a community
should agree upon which approach to use. While implementations should
should agree upon which approach to use. Whilst implementations should
support both methods, deployments may choose to disable the use of one
of them.</t>

Expand All @@ -897,7 +898,7 @@ Content-Type: application/json
target="OpenID.Registration">OpenID Connect Dynamic Client
Registration 1.0</xref>.</t>

<t>It is assumed that an federation entity has a set of
<t>It is assumed that a federation entity has a set of
authority_hints and knowledge about which trust anchor that can be
found at the end of a trust chain starting in each authorityHint. How
the entity has received this knowledge is outside the scope of this
Expand All @@ -912,9 +913,8 @@ Content-Type: application/json
<section anchor="Clireg" title="Client Registration">
<section anchor="Cliregreq" title="Client Registration Request">
<t>The OP MUST support dynamic relying party registration. That it
does so is signaled by have the claim
<spanx style="verb">federation_registration_endpoint
</spanx> in the metadata.</t>
does so is signaled by having the claim
<spanx style="verb">federation_registration_endpoint</spanx> in the metadata.</t>

<t>Given that the OP supports dynamic registration the RP
progresses as follows: <list style="numbers">
Expand All @@ -928,13 +928,12 @@ Content-Type: application/json
its own set that terminates in those trust anchors.</t>

<t>The RP will now construct a self-signed entity statement
where the metadata statement chosen is influence by the OPs
where the metadata statement chosen is influenced by the OPs
metadata and the authority_hints specified are picked by the
process described above.</t>

<t>The entity statement is sent to the
<spanx style="verb">federation_registration_endpoint
</spanx> defined in this document.</t>
<spanx style="verb">federation_registration_endpoint</spanx> defined in this document.</t>
</list></t>
</section>

Expand All @@ -946,8 +945,8 @@ Content-Type: application/json
the signature on the received registration request is
correct.</t>

<t>If it finds more then one acceptable trust chain it MUST
chose one or more that terminates in one and the same trust
<t>If it finds more than one acceptable trust chain it MUST
choose one or more that terminates in one and the same trust
anchor.</t>

<t>At this point, if there already exists a client
Expand All @@ -957,7 +956,7 @@ Content-Type: application/json
<t>The OP will now construct an entity statement containing a
description of the RPs metadata that the OP finds acceptable.
To the entity statement it will add one or more
authority_hints, from its collection, that terminates in the
authority_hints from its collection, that terminates in the
trust anchor chosen above.</t>

<t>It will sign and return the signed entity statement to the
Expand All @@ -971,7 +970,7 @@ Content-Type: application/json
referenced in the entity statement it sent to the OP.</t>

<t>If the RP is OK with the metadata that was the result of
the flattening of the received entity statement then it store
the flattening of the received entity statement then it stores
the configuration and can continue communicating with the OP
using the agreed on metadata.</t>

Expand All @@ -985,11 +984,11 @@ Content-Type: application/json
<section title="After client registration">
<t>A client registration using this specification is not expected to
be valid for ever. The entity statements exchanged all have
expiration times. Which means that the registration will eventually
time out. An OP can also for some reason decided that a client
expiration times, which means that the registration will eventually
time out. An OP can also for some reason decide that a client
registration is not valid anymore. To this can be added that the
entities in the federation, for a number of reasons, over time may
change how fast their signature will expires, thereby increasing or
change how fast their signature will expire, thereby increasing or
decreasing the lifetime of a trust chain.</t>

<section title="What the RP MUST do">
Expand All @@ -1010,7 +1009,7 @@ Content-Type: application/json
</section>

<section title="What the OP MUST do">
<t/>
<t>TBD</t>
</section>
</section>
</section>
Expand Down Expand Up @@ -1038,7 +1037,7 @@ Content-Type: application/json
<t>The client_id of the RP MUST be set identical to the RP entity
identifier.</t>

<t>Without a registration process, the RP does neigther have any
<t>Without a registration process, the RP does not have any
client_secret. Instead the implicit registration model requires the RP
to make use of asymmetric crypto.</t>

Expand All @@ -1057,21 +1056,21 @@ Content-Type: application/json
statement as described in <xref target="fetching-es">fetching entity
statements</xref>.</t>

<t>The OP should validate possible the trust chains, and resolve the
<t>The OP should validate the possible trust chains, and resolve the
RP metadata with type <spanx style="verb">openid_client</spanx>.</t>

<t>The OP should consider the resolved metadata of the RP, and
<t>The OP should consider the resolved metadata of the RP and
perform these additional validation steps:</t>

<t><list style="symbols">
<t>Verify that the metadata contain a public key... TODO: add
<t>Verify that the metadata contains a public key... TODO: add
proper reference.</t>
</list></t>
</section>

<section title="Authentication Error Response">
<t>If the OP fails to establish trust with the RP, it should use the
<spanx style="verb">error_description</spanx> error code, and an
<spanx style="verb">error_description</spanx> error code, with an
<spanx style="verb">error_description</spanx> that aids the RP to
fix what is wrong.</t>
</section>
Expand Down

0 comments on commit 1ca9cac

Please sign in to comment.