[Openid-specs-risc] RISC Profile

Wed Feb 14 19:21:17 UTC 2018

I don’t agree with Dick here. SET delivery *should* be straight forward.  We are passing URL safe strings to one another - lets not make this any more complex.

There is a diverse set of security configurations in all of the profile communities.  This is not a RISC is somehow specialized from the rest of the world.  Within RISC our own usage for implicit involves a lot of web applications that do no federation at all. They don’t use oauth nor OpenID (much as we would like them to). 

I have come to the conclusion that both RISC and SECEVENTs cannot make general assumptions about security environments. We can assume they will deploy HTTP the way they want to. 
—>The approach that SECEVENTs should take, is that delivery of SETS is a simple HTTP service and any secure HTTP configuration people want to use is acceptable. SCIM went through this same debate. You’ll notice while SCIM reviews some of the common security authorization techniques (e.g. OAuth) it stays silent on recommendations. The proof in the market-place is that this has not lead to interoperability problems for SCIM. Why?  Because people use what is common practice in their environments.

So what should we do with the profile draft???

I think it is reasonable for now, to define it as the "testing profile" for RISC. In a testing profile, it is fine to test out assumptions and simplifications to see if they are universal.  We must still keep in mind that many who can’t pilot right now may still have different requirements. E.g. Are there any implicit participants in the pilot?

As a testing profile, it also reminds participants that the drafts are subject to change as SECEVENTs evolves. But more importantly, it provides real implementation experience data from RISC to feed back into SECEVENTs without being seen as an initiative to fork SECEVENTs.

I want to make sure we get the SECEVENTs group working and in particular, work on the subject identification draft and get that done alone with the other items. —> Marius, we should get the chairs to amend the charter in this regard.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>

> On Feb 10, 2018, at 9:34 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
> 
> I don’t think this is a scim is different than risc is different than xxx issue. 
> 
> I do think there are many different environments within risc itself. 
> 
> Oracle has Palerra which works with web applications to detect and issue events. It has nothing to do with connect. — yet the objective would be to send events back to IDPs. While many consume id tokens, not all do. 
> 
> There are also implicit federation cases (email, telephone) which have nothing to do with connect. While some have oauth enabled mail, most do not. 
> 
> The conversation at Cisco gave me pause because all of these cases seemed excluded by assuming oauth token and oidc systems are present. 
> 
> I have concluded that the security (eg authorization header) config is highly variable when it comes to oauth etc. As much as I would like to impose a solution, the only one that seems repeatable is old fashioned mutual tls for server to server comms. Since any server can generated self signed certs. 
> 
> From my perspective just within risc we do not have a good solution other than manual config. 
> 
> I fear that this will add to the configuration hassles we already have that were trying to he addressed with fastfed. 
> 
> Phil
> 
> On Feb 5, 2018, at 1:11 PM, Hardt, Dick <dick at amazon.com <mailto:dick at amazon.com>> wrote:
> 
>>  
>>  
>> On 2/5/18, 12:38 PM, someone claiming to be "Openid-specs-risc on behalf of Marius Scurtescu via Openid-specs-risc" <openid-specs-risc-bounces at lists.openid.net <mailto:openid-specs-risc-bounces at lists.openid.net> on behalf of openid-specs-risc at lists.openid.net <mailto:openid-specs-risc at lists.openid.net>> wrote:
>>  
>> On Mon, Feb 5, 2018 at 11:29 AM, Phil Hunt < <>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>> wrote:
>> Marius,
>>  
>>  
>>  
>> Should discovery not be part of SECEVENTs?  
>>  
>> Could be. Several parts of this profile could theoretically be moved to secevent. First I think it makes sense to see a complete and consistent solution and then if the secevent working group shows interest we can look at splitting parts out.
>>  
>> Given there is not one in SecEvent now, it needs to be profiled in RISC
>>  
>> <snip>
>>  
>>  
>> Section 4 - we had discussions in Singapore that a majority of attendees indicated they need a multi-profile management API.  Why does the RISC document have one? 
>>  
>> We went back and forth on this quite a bit. The current management API proposes only one stream between one transmitter and one receiver. Allowing multiple relieve some receivers of the need to implement a dispatcher. We can definitely pick up that discussion.
>>  
>> I think “need” is too strong. A single management API is desired.
>> Another aspect is that the management requirements of RISC, SCIM, OIDC etc. so far look quite different.
>> RISC has specific needs, and with a concrete API, there can more easily be a discussion on commonalities, or lack thereof with other SecEvent profiles.
>>  
>> /Dick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180214/b50cfc53/attachment-0001.html>