# SIOP with OpenID Federation Entity Statements <!-- It is only a matter of time before I publicly type WS-Federation --> ```plantuml @startuml autoactivate on hide footbox skinparam monochrome true skinparam roundcorner 5 actor User control "Relying Party" as RP boundary "Redirect URI" as Redir boundary "Authorization Endpoint" as AE control "Self-Issued OP" as SIOP boundary "Resolvers" as VDR note over RP, SIOP Preconditions: * Creation of trust framework(s) which use OpenID Federation entity statements * RP and OP are members with entity statements up to trust authorities * RP has resolved entity metadata of issuer end note User->RP: request authentication\nand/or credentials RP -> VDR: resolve current SIOP metadata VDR --> RP: metadata RP -> RP: Create signed\nrequest object deactivate RP RP -> AE: request id_token note left request contains: client_id, response_type, request JWT end note AE -> SIOP: browser resolution\nfrom endpoint URI deactivate AE SIOP -> VDR: check for current RP metadata VDR --> SIOP SIOP -> SIOP: create local\nclient registration deactivate SIOP deactivate SIOP SIOP -> SIOP: process request SIOP -> User: user consent for disclosure User --> SIOP: consented deactivate SIOP SIOP -> Redir: response deactivate SIOP note right response contains: state, id_token end note Redir -> RP: response deactivate Redir RP -> VDR: check for current subject metadata VDR --> RP: signing key RP -> RP: verify response deactivate RP RP->User: transaction status or\nauthenticated session @enduml ```
Last changed by  
 
dwaite
318

Read more

Untitled

This document is obsoleted view source for contents

6/5/2023
Reconsilation Possibility for SD-JWT and JWP Proposals

Issuer creation: The issuer general several pieces of data e.g. base JWT payload, data to make selectively disclosable Generating releasable payloads: For each value: Generate random salt, create JSON text for salt, key and value (which can be any valid JSON structure):

11/7/2022
Events

OpenID Connect Call - September 20, 2021 W3C Federated Identity CG Call Documenting use cases of what would be considered in-scope Still in initial discussions (e.g. terminology) Some disagreements on where the line for unsanctioned tracking would be drawn Some consequences to the tracking document in the W3C not being updated EIC 2021 Attendee comments

9/21/2021
SIOP Properties

A.K.A. We should stop using "SIOP" as an umbrella term Note: This is meant to be for collaboration on the list of properties referenced in this OpenID issue. If you do not think there is concensus around a change, feel free to use the comment feature in HackMD (by selecting text in the rendered view) to start discussing the topic. Also, please describe changes made to this document while it is being collaborated on to the bulleted list at the bottom. Revisions to this document are tracked and are visible by going to the ellipsis menu (…) on the top right and selecting "Versions and Github Sync" There have been repeated misunderstandings when “SIOP” is used to describe an umbrella feature-set, especially when we are discussing creating subsets and extensions of these features to solve specific problems. This is an attempt to document all the existing properties that people may associate with SIOP today, for the purpose of identifying desirable properties and attempting to break them out as first-class behavioral concepts. The goal would be to eventually have specific feature names in discussions, and that “SIOP” is used exclusively as the name of the existing https://self-issued.me issuer.

6/16/2021
Read more from dwaite
Published on HackMD