OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: SV: [bdx] BDEA and Trust Frameworks


Hi Roger,

Please be excused if I am too direct - but can I kindly ask you to distinguish clearly between the work of the BDX TC, and the services/product you are marketing?

I would prefer to see the TC as 'neutral ground' where we leave the commercial interests at home - and work on a neutral basis.

My excuses if I raise concerns that doesnt need to be raised.

Best regards

Jens Jakob

--- Oprindelig besked ---
Fra: "Roger Bass" <roger@traxian.com>
Emne: RE: [bdx] BDEA and Trust Frameworks
Dato: 15. marts 2011
Klokkeslæt: 19:2116

Thomas, Mikkel et al,

 

Thanks for your comments, Thomas.  To your point, and ahead of tomorrow’s discussion, I wanted to follow up with some more specifics on possible Trust Framework use cases.

 

I like the BDX 4-corner addressing model, and how it leverages DNS.  But it’s materially different from the 3-corner user account model that’s predominant today, where every endpoint must have an account/identity on each network.  The basic issue is one of “how do we get there from here?”  For this committee’s work to have broad relevance, I think we need standards-based trust models that enable interoperability with 3-corner networks, and incremental migration to the 4-corner model.  Conceptually, the notion of an “Identity Proxy” may help create a bridge between the two models – something my company is implementing today.

 

In this context, we can group use cases into 4- and 3-corner scenarios, perhaps with some overlap.

 

1.       4-corner

a.       Creation of a DNS Service Metadata record

b.      Authentication of senders (and/or their service providers)

2.       3-corner (Identity Proxy)

a.       Establishing a new endpoint identity (? OpenID Attribute Exchange?)

b.      Binding to an identity for Single Sign On (OpenID)

c.       Binding to an identity for transaction exchange (OAuth)

d.      Endpoint identity validation

 

Best regards,

Roger

 

 

From: Thomas Gundel [mailto:tg@itcrew.dk]
Sent: Thursday, March 10, 2011 3:45 PM
To: 'Roger Bass'; bdx@lists.oasis-open.org
Subject: SV: [bdx] BDEA and Trust Frameworks

 

Hi Roger,

 

I agree with your points – a good starting point will be to outline the central use cases.

 

For your information, the PEPPOL specifications team did in fact look at Liberty Alliance and Kantara: for example the START profile

re-uses a lot of elements from Liberty Basic SOAP Binding specification (http://www.projectliberty.org/liberty/content/download/4654/31837/file/Liberty-Basic-SOAP-Binding-1.0.pdf). For example, SAML Assertions and X.509 certificates are used to convey the identity of the sender and the sender Access Point. The specifications allow many different trust models – but in PEPPOL it has been decided to use a centralized trust model with a PEPPOL PKI issuing certificates for all service providers in the infrastructure.

 

 

Best Regards,

Thomas Gundel

 

Fra: Roger Bass [mailto:roger@traxian.com]
Sendt: 10. marts 2011 19:57
Til: bdx@lists.oasis-open.org
Emne: [bdx] BDEA and Trust Frameworks

 

Mikkel, Thomas et al,

 

I’d like to introduce the notion of ‘Trust Frameworks’ for discussion as part of the BDEA (BEDA?) scope.  My apologies if I’m repeating topics from yesterday’s meeting, which I’m afraid I missed.

 

Various recently-posted committee documents touch on issues of security, trust, PKI infrastructure etc.  However, these fail to acknowledge that these are very general issues that are being addressed on an industry-wide.  The two main trust framework organizations are Kantara Initiative (which took over the work of the Liberty Alliance), and Open Identity eXchange (OIX).  The two organizations have announced that they are collaborating on certain topics.

 

Trust Frameworks aim to establish facilitate large-scale, federated identity management by profiling existing standards (notably OAuth, SAML, OpenID) around particular use cases.

 

It seems to me appropriate to the scope of this TC to:

a)      define relevant use cases within the BDEA context

b)      identify relevant use cases or profiles that may already have been established/published within existing Trust Frameworks

c)       conform BDEA use cases to existing best practices where possible

d)      as appropriate, to work with Trust Framework organizations to use case additions or extensions

e)      define conformant profiles for BDEA use cases around both technical, business and legal aspects of implementation

 

As a very preliminary, incomplete and perhaps overlapping list, BDEA “trust” use cases might include:

1.       Addressing: authenticating domain owners for creation of a new DNS Service Metadata record

2.       Supplier Network identity setup: automating creation of a new (supplier) identity on a supplier network

3.       Supplier authentication: validating that a new supplier identity does indeed correspond to an existing vendor record in the buyer’s system.

4.       Four-corner trusted party setup

 

I look forward to further discussion on this next week.

 

Best regards,

Roger Bass

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]