[Openid-specs-ab] SIOP Scope proposal

Torsten Lodderstedt torsten at lodderstedt.net
Thu Dec 3 12:11:37 UTC 2020


Hi,

I support the proposal. 

Splitting the current scope of SIOP into different modules has a huge potential for implementers to adopt dedicated modules. Especially the split between (1) and (3) makes sense to me as it would allow „classical“ OPs to support the assertion of portable identifiers, like DIDs. 

(5) is an useful addition for SSI bridging scenarios and (4) allows classical IDPs to become credential providers. 

Baseline: I think we could significantly contribute to the adoption of all kinds of self issued identities and position OpenID Connect as THE enabling technology in this context. 

best regards,
Torsten. 

> Am 03.12.2020 um 00:35 schrieb Tobias Looker via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
> 
> Hi All,
> 
> Over the past while, there has been a lot of interest and work going into a revision to chapter 7 of the OpenID Connect Core chapter (Self Issued Provider). It is my impression that because this chapter originally aimed to solve several quite large problems, we would benefit from classifying these better to ensure we can have the most productive conversations possible. My proposal, that I have already informally raised on the Pacific AB WG call, is to break apart the scope of SIOP into 5 separate problems.
> 
> 1. Enabling portable subject identifiers between providers - Define how to use techniques such as asymmetric cryptography and higher level technologies like Decentralized Identifiers to create subject identifiers that are not intrinsically bound to a particular OP and hence can be ported between providers.
> 2. Solving for provider discovery and registration - Evaluating solutions to problems like the nascar problem, how does an RP come to have a relationship with an OP or understand its capabilities along with what role the user plays in this selection/discovery process.
> 3. RP - OP co-location on the same device - Dealing with the unique requirements that are brought about when the OP the RP is communicating with is on the same device (e.g in the form of a PWA or Native App), rather than a traditional Authorization server.
> 4. Credential Issuance support - Issuing credentials from OpenID Connect flows.
> 5. Credential Presentation support - Presenting credentials in OpenID Connect flows.
> 
> Its important to note that in my opinion only problems 1,2 and 3 were in the original scope of the SIOP chapter however due to the continued evolution of the SSI/Decentralized Identity and Verifiable Credential space, many uses cases that SIOP has come to be associated with involve verifiable credentials and there for problems 4. and 5. should be addressed.
> 
> Thanks,
> 	 	
> Tobias Looker
> Mattr
> +64 (0) 27 378 0461
> tobias.looker at mattr.global
> 			
> 
> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
> 
> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://www.google.com/url?q=http://lists.openid.net/mailman/listinfo/openid-specs-ab&source=gmail-imap&ust=1607558455000000&usg=AOvVaw1pd6uoO4RW-KgfX2M8yyhn



More information about the Openid-specs-ab mailing list